VOL. 8, ISSUE 4, OCTOBER - DECEMBER 2015
Model Based Development - II
Modeling Tools
Automatic Code Generation in MBD
Model Based Design of Embedded Software for Hybrid Vehicles
Model Based Design for Aerospace and Defense Industry
Model Based Development and Mathematical Modeling of a
Simple Cruise-Controller- A Case Study
Modeling Aspects of Two Wheeler Dynamics
Best Practices for Model Based Designing in Automotive Industry
Design and Development of Muffler
Colophon
Zachary Schwab
Technical Advisor - Embedded Software Architect
Cummins Inc.
Rahul Uplap
AVP
rahul.uplap@kpit.com
Asavari Pradhan
Nitin Swamy
Contents
Editorials
Guest Editorial
Zachary Schwab
Editorial
Rahul Uplap
2
3
Scientist Profile
James Rumbaugh & Ivar Jacobson
Priti Ranadive
9
Book Review
Model-Driven Engineering for Distributed Real-Time Systems
Milind Potdar
19
Articles
Modeling Tools
Ranjith Kumar P. B.
4
Automatic Code Generation in MBD
Nitin Swamy & J Sandya
10
Model Based Design of Embedded Software for Hybrid Vehicles
Prajakta Tapkir
14
Model Based Design for Aerospace and Defense Industry
Kritika Thakral
20
Model Based Development and Mathematical Modeling of a
Simple Cruise-Controller- A Case Study
Rizwana Mujawar
24
Modeling Aspects of Two Wheeler Dynamics
Vishal Pillai
30
Best Practices for Model Designing
in Automotive Industry
36
Pallavi Kalyanasundaram & Varsha S. Pathak
Design and Development of Muffler
41
Vicky Choudhari & Priyank Vijapur
1
TechTalk@KPIT, Volume 8, Issue 4, 2015
Guest Editorial
Zachary Schwab
Technical Advisor
Embedded Software Architect
Cummins Inc. USA
2
TechTalk@KPIT, Volume 8, Issue 4, 2015
I recently had the bittersweet experience of hosting a retirement party for Dave, one of my employees. Dave
leaves a big hole in my group, but it was great to see someone who had given so much our company go off to a
well-deserved retirement. It also gave me an opportunity to reflect on the changes we've seen in our common
field of embedded controls. When Dave started his career, the state of the art engine controller was a single
purpose controller with code developed in assembly. Today, the state of the art is a complex high speed network
of multipurpose computers controlling every aspect of the machine. These controllers together make up a very
significant portion of the design effort, intellectual property, and overall performance and quality of the overall
products in which they reside. Given this background, while it might be difficult to speculate exactly what
changes a new engineer starting her career might witness over the next forty years, it would be foolish to imagine
that things will stay the same as they are now. The complexity, interdependency, and performance of our
embedded systems will undoubtedly increase for the foreseeable future, all while the margins for error decrease.
Model based controls has been a key factor in our ability as an industry to manage this complexity, and will be
even more critical to our work as time goes on.
The key benefit of model based controls is rooted in its ability to greatly accelerate the pace of development. With
it, today's developers may now work much more independently of the hardware and environmental issues that
bedeviled past engineers. With good plant models, new features may be prototyped, tested, and perfected in
simulation rather than a dedicated test bench or out in the field. This can be done before the machine or even the
control module is available, and given sufficient computing power, features can be simulated and tested faster
than real time. One of the phrases I've heard relating field testing is that “you can't reschedule winter,” but at least
for development, we now have flexibility to adjust any parameter in our model how we want it, when we want it. In
the simulation environment we can have winter whenever we want it.
Model based controls also accelerates development by allowing us to better focus on the conceptual and
creative side of our work. Early development was characterized by a much stronger focus on the mechanics of
how we realized our products. There was a lot of time spent figuring out how to translate the expertise of those
specialists who understood the physics of the product into the specialized language that machines could
execute. This process was time consuming and error prone. Today, model based development provides that
bridge between human concepts and machine language, allowing engineers to focus more on what it is they
need to do rather than how they will realize it.
With this greater focus on the conceptual machinery of our work, it follows that we can now also be more
successful at sharing and reusing those concepts across different products. It's true that platforms and product
lines predate the era of model based controls; they've been utilized in the mechanical world for years. However,
the modular nature of the models that we use makes it easier for a software architect to share content across
products. The planned reuse of key features across products can be a significant and positive impact on the
cost, quality and time to develop embedded controls for companies. The ability to easily copy and paste features
from one place to another make this reuse easier.
While the model based toolbox has been key to our success in the last decade, we shouldn't assume that we're
done developing and refining it. As shipbuilders moved from the era of sail to steam, they necessarily developed
far more capable and specialized tools. As we move from the world of controllers with a few sensors and
actuators to the world of fully autonomous and connected vehicles, we should expect the same in our own
industry. What changes and additions to our common toolbox should we be driving? You'll read some
perspectives on this topic in the pages that follow. My own perspective is that we must continue to improve the
accelerative capability of model based control while also developing tools to manage our complexity. To make
further productivity improvements, we're going to need to move further up model based development's ladder of
abstraction. It's common in our industry to compare model based development to building with Lego blocks. It's
a good analogy, and helps to illustrate my point. It's clear that we're changing from building small, simple models
to building very large, complex models. If we don't change the size of the blocks we're building with, it's going to
start taking an inordinate amount of time to put it all together. Furthermore, as our models get ever more complex
and interrelated, we're going to need better tools to visualize and analyze our systems. The ability to understand
and manage the functional and physical architecture of complex systems will be a key differentiator in the coming
years. Clearly, we're on an exciting journey in our industry. What follows in these pages is the discussion on how
model based development will be part of getting us to our destination.
Editorial
Rahul Uplap
AVP
KPIT Technologies Limited,
Pune, India
Last week, I was talking at a Mathworks seminar on the future of Model Based Technology and I
realized that how the software development technology has evolved by leaps and bounds over the
last couple of decades. Back in those days, a software engineer was an elite type, as only he would
know how to work with the ones and the zeros and make the machines obey his commands. Come
now and the same software engineer species is fast becoming extinct in today's world dominated
by technology relying on virtualization of as complex systems as aero planes and rockets and
automobiles.
The modern day engineer has an arsenal of technologies at his disposal that would help him build
the system as he visualizes, simulate its performance without even a single line of code being
written and then leave it to the same technology to spit out the ones and zeros to reproduce the
same behavior in the real world. But the ever increasing demand for enhanced intelligence in
various machines and systems with which the humans interact, is leaving the model based
technology ever catching up with these demands. The auto-code generators have seamlessly
replaced the human brain for writing software programs. This has helped the engineers to focus on
visualizing the product as well as the environment and build it block by block rather than worrying
about writing optimized codes. But the need for virtualization is throwing up many complex
challenges to accurately build today's products and reproduce the environment to guarantee their
performance.
The boundaries between various applications, industries, are fast becoming blur to build a product
packed with features emulating human intelligence. Autonomous Vehicles, which undoubtedly is
the future of automotive industry, is a perfect example where technologies right from classical
machine control to artificial intelligence, seamless communication between vehicles as well as the
surrounding infrastructure, makes simulation or I'd rather say, 'co-simulation', a necessity. Thus,
after the auto-code generation milestone achieved in the last decade, the next milestone to achieve
in next couple of decades for the model based technology would invariably be seamless cosimulation of these heterogeneous but complementary technologies. This is giving rise to
specialized tools focusing on specific domains and the challenge would be to seamlessly integrate
these different tools from various vendors interact with each other in a flawless manner. Thus,
standards like Functional Mock-up Interface (FMI), a tool independent standard to support model
exchange and tool coupling for co-simulation of dynamic models is rapidly evolving, helping the
engineers to bridge these multiple technologies together. This is a standard being developed in
collaboration with leading automotive OEMs, Tier-1s and universities.
According to me, another significant use case for the model based development technology to
address is, to ensure the product development and validation process is robust enough to develop
flawless products. Standards like ISO 26262 and Automotive Spice are fast being integrated in the
modeling workflows. But there are still vast areas for improvement, especially for ensuring
adequate coverage for use cases and associated requirements. OEMs still have to shell out
millions and billions of dollars on product recalls, which could certainly be reduced by delivering
robust products which in turn would need robust requirements. Thus integration of use case tools
with model design tools is another type of co-simulation that the tool vendors have to achieve fast.
Thus, there couldn't be more exciting times for the model based technology to address these
demanding needs of the industry to deliver robust and intelligent products in a timely manner. The
articles to follow would certainly shed more light on some of these challenges and ways to address
them.
Please send your
feedback to :
rahul.uplap@kpit.com
3
TechTalk@KPIT, Volume 8, Issue 4, 2015
4
TechTalk@KPIT, Volume 8, Issue 4, 2015
Modeling Tools
About the Author
Ranjith Kumar P. B.
Areas of Interest
Modeling in Matlab,
Programming for Automation (Matlab, Python, Macro),
HIL Testing tools (Automation Desk)
5
TechTalk@KPIT, Volume 8, Issue 4, 2015
Abstract
Model Based Design has been widely used in
automotive industry for developing reliable
and robust software to achieve safety &
sophistication in cars. Most of the functional
models of Power train, BCM, Chassis, etc. are
frozen and only few changes and tunings are
done for next versions. However, MBD tools
like Matlab are used till the testing stage of
software in Test platforms like dSpace HIL
setup. Using Matlab tools to support the
analysis of in-loop tests like MIL, HIL can be
built. One such case is the analysis of
measured test results which are in the form of
Matlab or CANape data format (.mat), or
CANape measurement file format (.mdf).
These MAT and MDF files can be analyzed in
CANape environment itself, but when there is
a need to analyze multiple measurement files,
the feasibility in CANape is limited and it
depends on programming languages like
C/C++ or DLLs. The analysis over multiple
files can be carried out in Matlab in which the
data can be filtered, synthesized, plotted and
further analysis can be done with the in-built
programming support available.
Also the present test results can be compared
with the previous test results to arrive at
conclusions.
Thus, the use of MBD tools like Matlab does
not stop with the algorithm/functional model
development. The journey of such graphical
tool continues until the software is tested
against requirements.
I. Introduction
In a Software Life Cycle, model based
approach consists of Design, Implementation
and Testing stages.
Matlab from
MathWorks is widely used during Design &
Implementation stages. Many of the
engineers use Matlab/Simulink/Stateflow for
developing a behavioral model with respect to
requirement specification. This functional
model is called as Executable specification.
Testing of this model before code generation
is called as Model in loop testing (MIL).
Later, this model is used for producing auto
code using third party tool or as a reference for
hand written codes. Testing of the auto code in
Matlab environment is called, Software in loop
(SIL) testing. The development activity in
Matlab environment is frozen at this stage,
when the code is available. Later, the
production code would be tested in a test
environment with real time simulation, i.e.,
hardware in loop (HIL) test and then in vehicle
testing.
6
Hardware in loop testing happens in simulator
TechTalk@KPIT, Volume 8, Issue 4, 2015
environment like dSpace, ETAS, Vector HIL
benches with ECU, where the need of the
modeling tool is very minimal like configuring
the HIL processor for integration, tracking the
signal flow model for analyzing the ECU
software.
System test
Requirements
Hardware in loop test
Modeling & Simulation
Auto coding
Figure 1: Model Based Development Life Cycle
II. Background
The basic concept of hardware in loop testing
is combining the vehicle simulator and a
particular feature which is going to be tested.
Vehicle simulators are plant models and the
feature model is called as application model.
Plant models are converted to binary codes
for flashing into the HIL processor board and
application model will be auto coded and
flashed into ECU. Here the only hardware is
ECU and remaining components including the
processor carries the simulation.
Vehicle simulators also called test benches
are developed by different vendors like
dSpace, Vector, ETAS, etc. Based on the
need, OEMs create their own test bench with
proprietary software. This software may allow
developing a plant model or provide libraries
to develop plant model.
dSpace products are built based on the
Matlab platform. Which means all the dSpace
products do work in Matlab environment and it
supports Matlab outputs like Simulink model,
.mat file. Some of the dSpace products used in
software testing are ControlDesk, Automation
desk, etc. ControlDesk is used in configuring
the processor board along with input/output
pins and acts as interface between .sdf and
processor.
III. dSpace HIL Test Environment
Test PC
Control desk / custom software
Canape
/ INCA
(.mdf/.
mat)
Plant model (.sdf)
dSpace / custom
Processor
configuration
dSpace / custom
processor
&
ECU (Application
software, i.e., auto
code from model)
Interfaces
Figure 2: HIL Test Bench Environment
dSpace HIL test bench has a plant model and
real ECU, where the application software is
flashed. The plant model is made as .sdf file
and flashed in the dSpace processor. Control
desk software acts as the interface between
the Matlab model and the processor.
IV. Testing
Test cases are written to test the application or
feature software for its functional
specification. During testing, the signals are
measured and recorded for analysis purpose
in the automated environment. For example,
while testing an electric power assist steering
system (EPAS), it would be required to check
the vehicle speed, steering wheel angle,
torque sensor signal, assist torque, etc. and
record them with respect to time. Vector
CANape is mainly used for measuring and
recording the signals as configured by the
tester.
V. CANape Overview
CANape is an all-round tool for ECU
calibration. The primary application area of
CANape is in optimizing parameterization
(calibration) of electronic control units.
Calibrate parameter values and
simultaneously acquire measurement signals
during system runtime. Among the basic
functions of CANape few are,
(a) Time-synchronous real-time acquisition
and visualization of internal ECU signals
with CCP/XCP, signals from CAN, LIN,
FlexRay and MOST buses as well as
external measuring equipment
(b) Offline evaluation of measurement data
from manual evaluation to automated data
mining with integrated script language or
user-generated DLLs.
(c) Processing of measurement values and
signals as well as automation of user input
sequences using the integrated script
language.
(d) ASAM measurement data format in MDF
and CAN bus data may be logged in either
BLF or MDF 4.0 format
VI. Result Analysis in CANape
Once the testing is over, it is necessary to
analyze the measurement file (.mdf / .mat file)
to know the behavior of application software
being tested. If there is any deviation, spike,
unexpected peak or noise in the measured
signal, it needs to be analyzed carefully. With
CANape it is possible to plot the measured
signals, evaluate the measurement data, and
print the results. But it lags in the below
requirements
(a) Repeating the evaluation steps to other
measurement data files in an easy step
(b) Printing the plots in a customized report
format
(c) Creation of new signals from the
measurement signals are not possible
without the help of external script
To achieve the above needs, it is necessary to
make work around in CANape and use
integrated script language or C/C++ functions.
Since the intended purpose of CANape is
recording the ECU signals, it is better to
evaluate multiple measurement files and do
the processing with signals using
programming languages. Since MATLAB is
already being used in the life cycle and it has
the potential of library functions and
flexibilities using m-scripts, the measurement
files can be imported in MATLAB and
processed.
VII. Analysis in Matlab
Though there are no direct functions available
in MATLAB to read MDF, BLF files, algorithm
shall be developed in m-script to read them
and import. Once the data is available in
Matlab, the signal which needs to be analyzed
can be plotted in a graph. The reference
signal, if any, can also be plotted in the same
graph and compared easily. A new signal
(error signal) that shows the difference
between reference and actual can be
produced and plotted to know the exact
differences. Apart from difference, a new
signal that is manipulated using the existing
signal(s) can also be produced.
Similarly, the cause and effect signals can be
plotted in a graph in Matlab environment. As
stated in the EPAS example, whenever there
is a cause (change in Steering wheel angle),
the effect (Torque sensor output, Assist
torque) can be analyzed visibly and
accurately.
Also, it is possible to copy the graphs to
external environment like Excel, PDF, etc. and
present the results and analysis as reports.
Matlab has in-built functions that help to
communicate with external environment like
DOS, MS Excel, PDF, etc. Using these
functions and APIs, it is possible to create
reports in custom templates.
VIII. User Interface
The analysis part mentioned above can be
completely automated and given to the user
as a tool for doing the analysis. In this tool,
user will be able to do the following:
Result Analysis Support
Load measurement File Listbox
Create Signal
Plot
Create report
Figure 3: Sample GUI for the Analysis Support Tool
7
TechTalk@KPIT, Volume 8, Issue 4, 2015
(a) Load MDF, BLF, MAT file
(b) Select the signal(s)
(c) Create new signals
(d) Plot the signals
(e) Save figures
(f) Create excel or pdf reports with the plots
(g) Threshold specification for the signals
(h) Save the steps (to repeat for other files),
etc
IX. Conclusion
In Model based development, Matlab plays a
vital role in making application model and plant
models. Another perspective of Matlab is
creating tools for supporting the analysis of
test results. In the above context, the use of
Matlab in analyzing the measurement files
(MDF,BLF,MAT) for supporting the dSpace
HIL test results are discussed. Also, the idea of
creating a user interface for integrating the
requirements is listed. There are other areas
where the programming ability of Matlab along
with its functions can be utilized to develop
tools. It is also cost effective, as this tool is
already used for modeling and simulation.
Hence, it does not increase the cost.
8
TechTalk@KPIT, Volume 8, Issue 4, 2015
References
[1] https://www.vector.com/portal/medien/
ecu_calibration/canape/animations_screens
avers/Vector_CANape7_At_a_Glance_EN.p
df
[2] http://home.hit.no/~hansha/documents/
lab/Lab%20Work/HIL%20Simulation/Backgr
ound/Introduction%20to%20HIL%20Simulati
on.pdf
[3] https://vector.com/vi_versionhistory_
detail_en,1042050,,1030841,detail.html
[4] http://www.mathworks.com/products/
simulink/?BB=1
Abbreviation
[1]
BLF – Binary Logging Format
[2]
GUI – Graphical User Interface
[3]
HIL – Hardware in Loop
[4]
MAT – binary Matlab file
[5]
MBD – Model based development
[6]
MDF – Measurement Data Format
[7]
MIL – Model in Loop
[8]
sdf – system description file
SCIENTIST PROFILE
Scientist Profile
James Rumbaugh
Ivar Jacobson
Born : August 22, 1947
Born : September 2, 1939
When one reads about Unified Modeling
Languages (UML) it is rare that one would not
read about the three amigos who developed
the UML. Grady Booch, James Rumbaugh
and Ivar Jacobson were given the nick of the
three amigos. In the previous issue of
TechTalk@KPIT we read about Grady Booch.
This scientist profile is dedicated to the other
two scientists viz., James Rumbaugh and Ivar
Jacobson.
James Rumbaugh was once asked in an
interview about his views on using UML to
generate implementation code. He
surprisingly disagreed with most of the UML
experts, stating that there is no magic about
UML and if it can be used for generating code
from a model then it is a programming
language; but, in that case UML is not a welldesigned programming language. This quote
actually shows how practically James
Rumbaugh would think about his own creation!
James Rumbaugh was born in 1947 in
America, who later on got his Ph.D from MIT in
Computer Science. He is best known for
creating Object Modeling Technique (OMT)
and UML. His career highlights are his work at
DEC, GE and later at Rational Software where
he met the other two amigos. It was at Rational
Software that they merged their different
techniques- OMT, OOSE and Booch to form
the Rational Unified Process (RUP). He later
moved to IBM and is retired since 2006.
James showed extreme interest in research in
formal languages, developing tools that would
increase productivity of programmers,
algorithms and data structures. He has
authored several books on object oriented
modeling, UML and OMT. His paper
publications are widely cited in the software
engineering field.
He needs no other glorification since his work
speaks for itself. Similar to James Rumbaugh,
Ivar Jacobson's contribution to the field of
software engineering has been significantly
impactful. He introduced the concept of “usecases” in one of his publications in 1992, in
which he writes “When a user uses the
system, she or he will perform a behaviorally
related sequence of transactions in a dialogue
with the system. We call such a special
sequence a use case.”
Ivar Jacobson was born in Sweden in 1939
and has a Ph.D. from the Royal Institute of
Technology in Stockholm. He began his
career with working at Ericson and later with
Rational Software and IBM. He is one of the
developers of the software and design
language which is a software standard in the
telecom industry. He formed his own
company in 2003,, viz, Ivar Jacobson
International with a focus to provide
consulting and training for large scale
enterprise agile software development.
From 2005 to 2009 he created EssUP
(Essential Unified Process), EssWork a
framework for working with methods and the
SEMAT (Software Engineering Method and
Theory) that focused on creating a
theoretically sound basis for software
engineering practices.
His paper publications have more than 24000
citations and his H-index (used to measure
the productivity and citation impact of
published work) is 27 as of today. He still
continues to publish his work, thus, continuing
his contribution to the field of software
engineering.
Both James Rumbaugh and Ivar Jacobson
have enormously contributed to the
component architecture, software
development and engineering fields. Along
with Grady Booch, the three amigos have
changed the modern engineering business.
About the Author
Priti Ranadive
Areas of Interest
OS, RTOS,
Parallel Computing,
Embedded Systems
9
TechTalk@KPIT, Volume 8, Issue 4, 2015
10
TechTalk@KPIT, Volume 8, Issue 4, 2015
Automatic Code Generation
in MBD
About the Authors
Dr. Nitin Swamy
Areas of Interest
Control Systems Analysis and Design,
Mathematical Modeling of Systems,
Hardware and Software Validation
and Verification
J Sandya
Areas of Interest
MBD, Programming for Automation (Matlab),
Real Time Target
11
TechTalk@KPIT, Volume 8, Issue 4, 2015
I. Introduction
The artefacts in Model Based Software Design
(MBSD) are called Executable Specifications
(ES). ES are non-textual implementation of
software algorithms, typically implemented in
tools like Matlab/Simulink. In order to create
standalone applications, these ES need to be
re-converted to code, which is then compiled
to create the application executable. Tools like
Matlab provide an automatic way to convert
the model into C/C++ code, along with
provisions to compile and link this generated
code. This process is called Automatic Code
Generation (ACG). This article tries to explore
the tools and methods for ACG.
II. What Does a Model Do?
Software specifications are generally created
from requirements. Once specified, in
traditional approaches, the requirements are
coded in some programming language (C,
C++,Java, etc.). In the Model Based Design
approach, instead of code, the same software
specifications are converted into a graphical
representation called a model. Consider an
example where the requirement is to add two
integers, a and b, and save the output into a
third integer c.
int add(int a, int b)
a
{
+
int c;
c=a+b;
_
c
b
return c;
Figure 1: Code to Model
The equivalent model for the code in Figure 1.
is now a high level representation of the logic
in the code. In a simulation environment like
Matlab, one can now change the inputs and
observe the function of the output without
having to compile and the executable for the C
code. It can be seen that the original static
specifications have been converted into ES,
i.e., it is now possible to validate the
specifications for various input values.
III. Automatic Code Generation
(ACG)
12
ES is an extremely convenient way to design
various software specifications and also to
validate these designs. However, most of the
embedded platforms still require code to be
compiled and flashed. Therefore, any design
in the form of an ES cannot be directly ported
to an embedded platform. The requirement
now would be to re-convert the ES design into
programming languages, usually C or C++.
TechTalk@KPIT, Volume 8, Issue 4, 2015
Fortunately, tools like Matlab provide utilities
that can take the ES as an input, and churn out
C/C++ code automatically. This process is
called as Automatic Code Generation (ACG).
Some common ACG tools include the
Embedded Coder (Ecoder) from the
Mathworks and TargetLink from dSpace
gmbh.
IV. Does The Es Exactly Capture All
Requirements?
An ES, while capturing the essence of the
requirements, may not in general be an exact
graphical replica of all the specifications. To
understand this, consider the C code in Figure
1.
The code specified a function add() with two
integer arguments. The output of the function
is also an integer. The function add() performs
addition of its input variables and saves the
result in the output variable.
In the ES representing this code, it can be
seen that, while the functionality of the
specification (i.e., addition of two numbers) is
captured, it is not clear that the inputs need to
be defined as integer variables, the output is
also an integer variable and the operation
needs to be in the form of a function.
In order for the ACG to perfectly re-create the
ES design in code, it becomes necessary to
add certain embellishments or special blocks
to the designed model. These blocks now add
the missing information specified by the
original code.
a
Convert
Convert
+
_
c
b
Figure 2: Preparing Model for Autocoding
As shown in Figure 2, to ensure that all inputs
and output are integers, data type conversion
blocks are added in the signal lines for both
inputs. The output by default then is also of
integer type.
Also, to ensure that the ACG outputs a function
called add(), all the blocks pertaining to the
addition operation are enclosed in a Simulink
subsystem. This indicates to the code
generator that everything within this
subsystem has to be re-converted to code as a
C function.
Some further examples of model
embellishments and their effect on generated
code is given below :
 Arithmetical operations such as
multiplication of two or more operands are
carried out in Simulink using product
blocks. This way of modeling may create
problems when the model is translated into
fixed- point† code by a code generator
Intermediate results must be calculated as
they cannot be determined automatically by
the code generator.
 Product blocks with more than two inputs
are prohibited in models used for
production code generation. A cascade of
product blocks with two inputs should be
used instead.
V. ACG Tools – Embedded Coder
from the Mathworks
Embedded Coder (formerly called Real Time
Workshop-EC) is an autocoding engine
provided by the Mathworks. It works on
models built in Simulink and Stateflow. Some
of the features of this utility are [1]:
 Optimization and code configuration
options
 Storage class, type, and alias definition
using Simulink data dictionary capabilities
 Processor-specific code optimization
 Multirate, multitask, and multicore code
execution with or without an RTOS
 Code verification, including Software in
Loop and Processor in Loop testing, custom
comments, and code reports with tracing of
models to and from code and requirements
 Integration of Texas Instruments'
Code Composer Studio™, Analog
Devices™VisualDSP++®, and other thirdparty embedded development
environments
 Standards support, including ASAP2,
AUTOSAR, DO-178, IEC 61508, ISO
26262, and MISRA C® in Simulink
General Facts About Traffic
1. In 2010, a traffic jam on a highway near
Beijing kept cars stuck in traffic for more
than a week (9-12 days according to different
sources). The traffic jam itself went on for
97 kilometers. The locals sold food and
water to the drivers for prices that were 10
and more times higher than normal.
The congestion was caused
by trucks carrying coal to Beijng.
2. Guinness World Records claims that what
happened in China wasn't the longest traffic
congestion in history though. An older jam
happened in France, spanning from Lyon to
Paris, and is regarded as the biggest
congestion ever. It stretched for 175 km and
took place on February 16, 1980. The reason
is told to be poor weather and a huge number
of cars on the French Autoroute.
3. The very first traffic lights were a manually
operated and gas-lit. They were installed in
1868 outside the Houses of Parliament in
Westminster (the UK).
4. The European patent office holds more
than 5 000 listed inventions relating to
traffic lights
5. In 1928, Charles Adler Jr invented traffic
lights that could be activated by drivers honking
6. Road traffic crashes cost countries up to
4% of their Gross National Product
7. Correctly used seat-belts reduce the risk of
death in a crash by 61%
8. Simple low-cost engineering measures are
saving thousands of lives
Reference
[1] http://in.mathworks.com/products/
embedded-coder/features.html#keyfeatures
9. Bill Gates' first business was Traff-O-Data,
a company that created machines which
recorded the number of cars passing a given
point on a road.
13
TechTalk@KPIT, Volume 8, Issue 4, 2015
14
TechTalk@KPIT, Volume 8, Issue 4, 2015
Model Based Design
of Embedded Software
for Hybrid Vehicles
About the Author
Prajakta Tapkir
Areas of Interest
Model based design,
Embedded Systems & Image processing
15
TechTalk@KPIT, Volume 8, Issue 4, 2015
Model based methodologies have become
the mainstay of research on embedded
systems development. Adoption of these
methodologies in industrial practice is able to
amortize the cost on large volume products
due to availability of open source software
tool.
I. Introduction
Most of the development of embedded
software is based on low level languages and
intense prototype activities. Model based
methodologies have emerged as the most
convincing alternatives for embedded
development. [2], [3].Model based design
reduces the distance between high level
control algorithms and their actual
implementation. This is achieved by starting
with abstract models and moving to the actual
code through refinements which preserves
already verified properties.
Despite the higher productivity that can be
achieved with these methods, there are large
industrial sectors (especially the small and
medium enterprises) whose production
volumes do not justify the significant
investment required for tools and training.
Emergence of low cost tools with appropriate
methodologies could preserve the advantage
of model based development. The tools
employed in realistic case study are open
source and include Scicoslab or Scicos [7] for
modeling the system and the control
algorithms, and the open source OSEKcompliant operating system Erika Enterprise
(8). Modeling phase, simulation results, and
its implementation on actual hardware is
further described.
II. Problem Description
The main difference between a hybrid and a
conventional vehicle is the presence of
electric motor and an internal combustion
motor. The internal combustion motor is
exclusively used to recharge a battery in a
series hybrid vehicle.
A speed controller sets the electrical motor at a
reference speed, an ignition controller
controls the torque production and a lambda
controller manages gas emission.
The design must satisfy three important
constraints:
1) Low target price of the vehicle
2) Low production cost for Small Medium
Enterprise (SME)
3) Short time to market
III. Methodology
Model-based methodology used to design the
controller for the hybrid vehicle is based on the
constraints as discussed in the earlier section.
Functional design which is a phase of platform
based design produces a mathematical model
that describes the plant (the hybrid vehicle)
and the controllers (speed, ignition and
lambda controllers).
Plant model starts by constructing the generic
model of each component used in the vehicle.
The next step is to identify parameters of the
actual components for the generic model. This
step is carried out by collecting data from the
technical documentation of the components
and by running experiments. The controller
models are designed using control
engineering techniques to satisfy certain
control goals.
To ensure all control goals are met,
simulations are run on the functional model.
Figure 1 shows an overview of the functional
design phase. The boxes represent
processes, whereas the curve boxes
represent functional design artifacts.
However, validated results from functional
design are given to mapping phase.
Refinements in plant model, code generation,
scheduling are components are part of
mapping phase as shown in Figure 2.
Parameter
Identification
Plant model
Traditional automotive technology used single
conversion of energy (chemical→mechanical)
approach. Electric motor provides the
propulsion which utilizes the energy stored in
the battery. This will achieve optimized power
consumption and emissions. Energy loss in
converting the energy twice (chemical→
electrical→ mechanical) is the main drawback
here.
16
It is a difficult task to design the controllers for
the hybrid vehicle based on design goals and
constraints.
TechTalk@KPIT, Volume 8, Issue 4, 2015
Plant
Modeling
Control goals
Control
Design
Timing
Requirements
Control
model
Simulation
No
Validation
Yes
To mapping
phase
Figure 1. Overview of Functional Design Phase [1]
 The catalyst pipe
Controller model
Refinement
 The electrical power-train, which consists
of the alternator, the rectifier, the battery
and the electrical motor
Device model
 The vehicle dynamics. [1]
Refined
Controller model
Performance
Analysis
Internal Cimbustion
Engine
Bypass Time
RTOS binding
Code
Generation
Timing
Requirements
Computation
Time
Tail Piple
Relative Oxygen Level
Electrical Power Train
Pressure
Air mass
Air / Fuel mass
Current
Throttle Valve
Position
RTOS config
Catalyst Pipe
Bypass
Valve
Intake
Manifold
Cylinder
Torque
Alternator
Speed
Battery
Voltage
DC Motor
Torque
Vehicle
Position
Engine Position
Task Code
Engine Rotation Speed
External Forces
Schedulable
Spark Advance
RTOS code
Compiler
Yes
No
Executable
Back to functional
design or
architectural change
Figure 2. Overview of Mapping Phase [1]
The Matlab tool suite is useful for the
development of mathematical models of
hybrid systems, and can be easily enriched
with additional features that carry
out specialized operations required in
distinct areas of application. This makes
Matlab/Simulink the preferable tool suite for
methodology. This application emphasizes on
methodology for SME. Therefore, different
tool suite which has lower acquisition cost is
required.
Open source software packages such as
Scicoslab/Scicos are available as a tool suite
for methodology.
This tool is suitable to evaluate the
methodology. While it may have some
drawbacks from a usability point of view, its
strength lies in the rigorous mathematical
underpinning.
Matlab/Simulink tools facilitate event driven
dynamics by providing a set of modeling
primitives for hybrid vehicle. Low level
modeling of hybrid dynamics are explicitly
provided in Scicos model. Consider the
problem of detecting state switches in a
cylinder of a four-stroke engine. Events have
to be generated every time the piston reaches
the dead centers. In Scicos, the events can be
manually generated based on the values of
the angular position of the crankshaft.
Figure 3. Overview of the Model [1]
The internal combustion engine produces the
torque and air-to-fuel ratio. The air fuel ratio is
taken as an input to the catalyst pipe and
produces the oxygen storage. The torque is an
input to the power train consisting of the
alternator, the rectifier and the DC motor. The
output of the electrical power train is the torque
applied to the wheels of the vehicle. The
torque, along with load torques from the
environment, is an input to the vehicle
dynamics and determines its motion.
Let us now see how to perform the functional
design for a particular component in the
system. Here, as an example, we have
selected the battery, since it is one of the most
complex components in a model.
The vehicle uses lead-acid batteries due to
their low cost. The battery pack consists of
eight 12V batteries arranged as two parallel
series of 4 batteries each. The total capacity of
the battery pack is about 84Ah, whereas the
output voltage is in the order of 48V. Battery
model is developed by Ceraolo and Barsali [4],
[5].
The considered battery model describes the
dynamics of a lead acid battery when it is
charged and discharged in different operating
conditions.
State of Charge (SOC) is an indicator of how
full the battery is compared to its maximum
capacity at temperature θ. It is given by the
following equation:
SOC = 1-
IV. Hybrid Vehicle
A very high-level view of the hybrid vehicle
system is as shown in Figure 3.
It has four macro-components:
 The internal combustion engine, which
consists of the intake manifold, the bypass
valve, and the one cylinder engine
Qe
C(O,O)
Where C(O,O) is the function that computes
the battery capacity and
Based on the mathematical model of the
battery, constructs the Scicos model that is
shown in Figure 4.
17
TechTalk@KPIT, Volume 8, Issue 4, 2015
Figure 6 shows the current drain of the battery.
Negative current means that the current is
flowing out of the battery, i.e. into the electrical
motor. Reducing the motor speed also reduces
the current required to run the motor.
Model based methodology chooses a control
strategy based on the simulation of the
system. It also provides flexibility in designing
and testing different control algorithms.
Figure 4. Scicos Model of the Battery [1]
The charge/discharge current is regarded as
an input and the voltage is regarded as an
output in battery model. Positive current
values indicate that the battery is being
charged and negative current values indicate
that it is discharged. Figure 5 shows simulation
results for charging and discharging the
battery.
V. Conclusion
Model based methodology for embedded
system development is based on the use of
open source software tools. In order to show
the concrete applicability of this methodology,
we have modeled the electromechanical
components of a hybrid vehicle and digital
controller for RPM control and emission
control. The Scicos model is constructed
based on the mathematical model of the
battery.
48
discharging
47
Voltage (Volt)
charging
46
References
45
discharging
44
[1]
43
Tizar Rizano,Roberrto,David,Luigi
Palopali,“Model based design of embedded
control software for hybrid vehicles.” Industrial
42
0
5000
10000
15000
20000
25000
30000
35000
40000
Time (Second)
Embedded Systems (SIES), 2011 6th IEEE
Figure 5. Simulation Results for Charging and
Discharging the Battery [1]
International Symposium, 15-17 June 2011.
[2]
Here, complete model of hybrid vehicle and
three controllers are described. Having a
complete model of the system and the
controllers gives us the flexibility of simulating
the complete system or only parts of the
system.
pp.19–25, 2003.
[3]
systems: Formal models, validation, and
RPM (deg/sec)
Current (Ampere)
synthesis,” Proceedings of the IEEE, vol. 85, no.
3, pp. 366–390, 1997.
[4]
M. Ceraolo, “New dynamical models of lead-acid
batteries,” IEEE Transactions on Power Systems,
vol. 15, no. 4, pp. 1184-1190, 2000.
[5]
S. Barsali and M. Ceraolo, “Dynamical models of
lead-acid batteries: Implementation issues,” IEEE
Transaction on Energy Conversion, vol. 17, no.
1, pp. 16–23, 2002.
[6]
0
5
10 Time (second)
15
20
A. Balluchi, L. Benvenuti, M. Di Benedetto, T.
Villa, and A. Sangiovanni-Vincentelli, “Idle speed
25
control–A benchmark for hybrid system
10
0
research,” in Proc. of the 2nd IFAC Conference
-10
-20
-30
-40
-50
-60
-70
-80
-90
on Analysis and Design of Hybrid System
(ADHS06), Alghero, Italy, 2006.
0
18
S. Edwards, L. Lavagno, E. Lee, and A.
Sangiovanni- Vincentelli, “Design of embedded
Simulation of the complete system for 10
seconds requires 1.4 hours as shown in the
Figure 6. However, internal combustion
engine model simulation for 60 seconds
requires 5 seconds. The complexity in the
electrical model, especially, the alternator and
rectifier that requires very frequent switching
will take a long time for testing the complete
model.
700
600
500
400
300
200
100
0
B. Selic,“The pragmatics of model-driven
development,” Software, IEEE, vol. 20, no. 5,
5
10 Time (second)
15
20
Figure 6. The Simulation Results of the Electrical Motor Model
and the Battery Model [1]
TechTalk@KPIT, Volume 8, Issue 4, 2015
25
[7]
http://www.scicoslab.org/
[8]
http://erika.tuxfamily.org/
BOOK REVIEW
BOOK REVIEW
Model-Driven Engineering for
Distributed Real-Time Embedded Systems
Author - Jean-Philippe Babau,
Mireille Blay-Fornarino, Joël Champeau,
ylvain Robert, Antonio Sabetta
It was a dream to design and develop complex
system with traditional tool having low cost,
minimum time and upmost quality. The dream
came true with Model Based Design (MBD).
MBD made life simpler and boosted
development in lesser time and cost. “Model
Driven Engineering for Distributed Real-Time
Embedded Systems 2009: Advances,
Standards, Applications and Perspectives”
gives practical perspective to develop complex
embedded system using Model Driven
Engineering (MDE) and Model Driven
Architecture (MDA). This book talks more
about new MDE technologies, its practices and
methods. This book is written by the industry
and academic experts.
This book is a combination of both theory and
practice. This book describes the developer's
choice of appropriate modelling languages
and transformation rule in Model Driven
Engineering for real time system. The authors
talk about effective model transformation and
its various methods with examples. For
instance, authors use different modelling
languages with emphasis given to UML and
talks about merits and demerits of the
languages as well.
Authors explain the power of MDA approach to
capture platform model and lists various
benefits such as reusable, platform
independent model, simpler and easier view
as well as understanding the model and
avoiding redundancy in maintaining different
Platform Independent Models (PIM), Platform
Specific Models (PSM), and Platform Specific
Implementation (PSIs). Authors make sure
that the developer generates sophisticated
code to realize complex real time embedded
system.
Illustrated testing aspects show authors'
expectation from developer/tester for their
possible approach to evaluate their quality of
system. While explaining testing aspect,
authors describe issues with selection of
particular test models in large space of input
model/models for transformation. Also, the
authors highlight challenges for selection of
test data in large domains and generation of
testing configuration in order to obtain
meaningful combinations.
Even though the authors have put more
emphasis on UML, they do not recommend
usage of any single modelling language. It is
clear that due to varying nature of embedded
systems, it is not possible to cover all the
aspects in development and testing of model.
Authors have illustrated advantages of
multiple strategies using SysML language and
MARTE profile in examples.
The authors justify all approaches using
various examples like testing, software
process, System on Chip (SoC) design using
Hardware Defined Language (HDL) and many
more. This book is written considering the
needs of a beginner as well as a professional.
Lot of examples and references make this
book substantial.
Author
Milind Potdar
Areas of Interest
Embedded Hardware and
Software Development,
Mechatronics, Cryptography,
Real time OS,
Communication, IoT
19
TechTalk@KPIT, Volume 8, Issue 4, 2015
20
TechTalk@KPIT, Volume 8, Issue 4, 2015
Model Based Design for
Aerospace and
Defense Industry
About the Author
Kritika Thakral
Areas of Interest
MBD,
Artificial Intelligence,
Cryptography
21
TechTalk@KPIT, Volume 8, Issue 4, 2015
I. Introduction
We all are aware of complexity involved in
designing and building aerospace vehicles.
The reasons behind this complexity include
security, integrated complex unpredictable
components, huge investments, difficulty in
t e s t i n g o n g r o u n d , f u e l e ff i c i e n c y,
environmental impact etc. These vehicles are
built from large complex integrated systems
that interact with each other in an
unpredictable manner. These kinds of
interactions make it difficult for aerospace
engineers to analyze and predict the behavior
of aerospace vehicles before they take first
flight.
Testing for such vehicles cannot be done
unless they are physically present and ready
to take off. It is difficult to predict whether the
idea, methodologies, concepts, designing and
all work done for developing aircraft will work
and bring in revenues for companies in future.
How can engineers ensure that the
components will behave as desired prior to
first flight? That is a big question and makes it
difficult for companies to decide whether they
should invest in a new idea in this industry,
since the investments will be huge and return
on investment may take years to come.
The level of complexity increases when we
add defense to it. Consider Aerospace and
Defense Industries together as one entity.
Aerospace vehicles are highly used in
defense, be it Army, Navy or Air Force. These
industries need highly accurate, fast, safe,
and reliable solutions. Aerospace companies
have to adhere to many criterion, keeping in
mind the special requirements while designing
aircraft for Defense Industry. For example,
defense aerospace vehicles may need higher
speed, lesser area for take-off & landing,
design that can keep soldiers safe during
wars, in extreme weather conditions anytime
in conflicted zones.
Model Based Design (MBD) is used to
address all such challenges.
Model Based Design allows aerospace
engineers to prepare architectural designs
and analyze the complex components at the
Concept & Design Phases. MBD helps to
predict the accurate behavior of such vehicles
in virtual environment much before they are
physically developed. It allows testing of
designs, processes, and behavior of
components at every stage of modeling.
 providing robust solutions by keeping in
mind the paramount concerns of these
industries like bird strike, impact of icing, I
lightning, safety of passengers etc.
In simple words, MBD empowers engineers to
build the safest aircraft by fulfilling the abovementioned requirements.
II. Few Ideas Designed Using MBD
Let us take some real life examples to discuss
this more. These examples are case studies
of two successful aircrafts designed using
MBD.
1) The Hero of this article: Tilt-Rotor
Here comes our Hero, Tilt-Rotor Aircraft. TiltRotor is an aircraft that has powered
helicopter- like rotors on both of its wings..
Image 1: Tilt-Rotor Aircraft
A Tilt-Rotor, shown in Fig. 1, has capabilities of
an aircraft as well as of a helicopter. The
powerful rotors on its wings allow it to take-off
and land vertically like a helicopter. Therefore,
it does not need a runway to take off and land.
A Tilt-Rotor can fly at a speed, which is double
the speed of a helicopter. Its powerful rotors
become forward tilted when it flies and gives
more thrust which makes it fly faster and
higher. That is why this aircraft is called as TiltRotor.
In this article, we will learn about two very
successful Tilt-Rotors, one is meant for
commercial use and the other is going to be
the future of Army. One of the successful
commercial Tilt-Rotors is BA-609 whereas; the
one for army use is V-280. Both the aircrafts
have become successful with the use of MBD
and Software & Hardware simulators.
2) Tilt-Rotor for commercial use
We will begin with BA-609 shown in image. 2,
the first successful commercial Tilt-Rotor of
the world.
Many activities are done by MBD and software
& hardware simulators in these industries
such as
22
 predicting the reliability, accuracy, safety of
operations and avoiding unexpected
design-related issues
 allowing aerospace engineers to use
automation and customization with
innovative designs
 helping vision and technology to come
together with cost effective solutions
TechTalk@KPIT, Volume 8, Issue 4, 2015
Image 2: BA-609
Bell Agusta 609 (BA 609) took its first
successful flight in the year 2003. It is the
world's first commercial Tilt-rotor, probably the
fastest and safest tilt-rotor yet. Its launch was
a revolution in commercial aviation market.
The intended use of this aircraft was to serve
as private jets for VIPs, as a private business
aircraft and for Oil & Gas expansion
operations. It has space for nine passengers,
can fly double the speed of a helicopter and up
to an altitude of 25,000 feet. Presently it is
priced at USD 24 million.
Government for safety & rescue missions and
medical emergency services in troubled
zones also use it.
MBD was used to develop this Tilt-rotor.
Simulink, an MBD tool was used to prepare
designs, refine the designs, perform testing
and verify the behavior on simulators.
Because of this, BA 609's first flight was
so smooth and seamless that it went exactly
the way it was on simulators during Simulation
Testing. It helped engineers to be sure and
predict the flight behavior prior to its first actual
test flight.
3) Army's Future with Tilt-Rotor
III. World's First Successful Tilt
rotor
In this article, we discussed about two TiltRotors; BA-609 and V-280. These aircrafts are
recently developed. Tilt-Rotor, BA-609 was
launched in 2003 and V-280 will be completed
by 2017. However, the very basic concept of
having an aircraft that can take off and land
vertically like a helicopter was first thought in
1930. The world's first Tilt-Rotor named as
Transcendental 1-G, one seat aircraft, shown
in Fig. 4, took its successful flight in the year
1954.It flew successfully but could not do
much than hover like a chopper. Later,
aerospace engineers started developing TiltRotors by using MBD tools, which were in
demand in Defense Industry especially in
Army. The idea behind a Tilt-Rotor, a flying
machine with a capability of an aircraft as well
as of a chopper, is a great idea. Nevertheless,
it is the MBD technology and it's Tools that
have given new direction to this idea by
making it a success story.
Let us discuss about the next Tilt-rotor, V-280,
which has been predicted as a future vehicle
for the Army.
Image 4: World's First successful Tilt rotor,
Transcendental 1-G
IV. Conclusion
Image 3: V-280
The concept of V-280 was first presented by
Bell Helicopters in 2013 in Texas. Aircraft
shown in Image 3 is a model of V-280 TiltRotor. V-280, presently, is in early
development phase and will be ready to take
its first flight by 2017.
V-280 will be able to carry 4 crew members
plus 14 passengers with a range of 1400 kms.
It will have the capacity of flying on its own with
complete ground control in conflicted zones.
This can save the need to send soldiers at
such areas. This aircraft will fight on behalf of
soldiers. For V-280, greater emphasis is given
on weight reduction and faster flying.
These tilt-Rotors will be developed by using
Fly by Wire Flight Control Systems. Fly by
Wire is an electronic system, which sends
signals to computers through wires
(channels). The advantage of using this
system is that it does not require pilot to give
inputs. It can automatically recognize the
changes through computer signals and detect
the movements or changes that occur. Based
on that, the aircraft is self-stabilized.
V-280 is being designed especially for Army
use. It is going to be the future battle aircraft for
the Army, when it gets commissioned in 2017.
The designing, development, testing and
verification of its prototypes are done by using
MBD tools.
MBD is used in various industries like
Aerospace, Defense, Automotive, Robotics,
Energies etc. It helps aerospace engineers to
choose best components for aircrafts, allows
them to design, develop, test and verify flight
behavior with respect to all the essential
requirements. Even though projects of this
industry require huge amount of investments,
MBD can justify the reasons for huge
investment as compared to the traditional way
of development. MBD allows concept and
design flaws to be corrected at a much earlier
stage in development as compared to
conventional design methodologies.
References
[1] Aerospace Technology BA 609 http://www.aerospace-technology.
com/projects/ba609/
[2] Business Insider V 280 Future of Army http://www.businessinsider.
com/this-tilt-rotor-aircraft-could-be-the-future-of-the-us-armyshelicopter-fleet-2015-1
[3] Robb report BA 609 http://robbreport.com/aviation/agustawestland
-aw609-tiltrotor-part-plane-part-helicopter
[4] Army Technology V-280 http://www.army-technology.com/projects
/v280-valor-helicopter/
[5] Bell Helicopter http://bellv280.com/bell-helicopter-exhibits-v-280tiltrotor-mockup-at-army-aviation-summit/
[6] Transcendental Tiltrotor http://www.vstol.org/VSTOLWheel/
TranscendentalModel1G.htm
[7] NASA PDF Tiltrotor History http://history.nasa.gov/monograph17.pdf
23
TechTalk@KPIT, Volume 8, Issue 4, 2015
24
TechTalk@KPIT, Volume 8, Issue 4, 2015
Model Based Development and
Mathematical Modeling of a
Simple Cruise-ControllerA Case Study
About the Author
Rizwana Mujawar
Areas of Interest
Mathematical Modeling,
Three dimensional data analysis,
Mathematical coding
25
TechTalk@KPIT, Volume 8, Issue 4, 2015
I. Introduction
1) Phase – One
Model based development is best described
as “Graphical programming tool” i.e.,
programming plus visualization through
graphics. But it is not just regarded as
graphical domain specific language. Instead it
is a paradigm used for system development
besides domain specific languages that occur
during development process in terms of
product and process. The main advantage of
Model Based Development is that it increases
the level of abstraction and thus simplifies the
development of large complex trivial system
which makes life easy for an inexperienced
user or a nuance.
We will also consider some standard
approximation of various calibrations and
constants in international metric system like
air density, coefficients of drag, coefficient of
friction, wheel radius and so on. These
approximations are data collected through
various web searches for different real time
cars like Chevrolet Corvette C5 Z06, Alfa
Romeo 147 GTA and so on.
We will enhance our understanding of modelbased development in the context of
“Automotive system”. This article describes a
case study on model based development and
mathematically modeling for a cruise
controller which reads target vehicle speed
and the current vehicle speed to regulate the
speed of the vehicle using MATLAB Simulink
Application tool. We will also take into account
both internal and external environmental
conditions like aerodynamic drag, rolling
resistance, engine force etc.
2) Design of Proportional
Integral Controller
The mathematical formula for a Proportional
Integral controller is:
u (t) = [Kp × e (t)] + [Ki ×
Here e (t) is the error between the target and
vehicle speed. Correction factor, kp is applied
to the error and ki is applied to integral of the
error. This system will be developed using
MATLAB Simulink application tool.
0.5
Kp
1
Saturation
1
s
Integrator
Add
Add 1
Product1
1
Ki
II. Case Study
In this article, we will look into the
mathematical modeling of simple cruise
controller. This cruise controller will simply
control the speed of the car and keep it moving
straight in a driving lane. A simple layout for the
design is as follows:
Figure 2: Model of PI Controller
The simulation result is as follows:
Vehicle speed
Target speed
08
The proportional Part of PI controller to
07
the throttle stays upto 0.25 later Integral
06
Aerodynamic drag
04
Rolling resistance
03
Engine
force
Vehicle speed
02
Vehicle speed
Throttle output
Y-axis : Target speed, X-axis : Vehicle speed
1
09
05
Vehicle speed
Proportional Integral
controller
Product
Step
Constant
linearly with slope being set to the speed
Before
I see,
Speed
diffence
is zero
At one sec, Integral part of PI controller kicks in and set
the speed difference to 0.25.
Final step = 0.5, Kp = 0.5
Speed difference = 0.25
01
Engine
force
Gear
0
0
Slope = 0.25 = speed
difference
part kicks in and the speed difference rises
1
2
3
4
5
6
7
8
9
10
Vehicle speed
RPM
Figure 1: Layout of Cruise Control Design
Mathematical formulae used while
designing the cruise controller are listed
below.
t
Proportional Integral controller
e(t) dT]
u (t) = [Kp x e (t)] + [Ki  
o
v(t)  a(t)dT
o
t F(t)
v(t)   dT
o m
Force
Engine force - Aerodynamic drag - Rolling resistance
i.e. F(t) = Fengine (t) - Fdrag (t) - Fres (t)
Aerodynamic drag
Fdrag(t)  Kdrag  v 2(t)  1/2  p  Cd  A  v 2(t)
Rolling resistance
Fr = c x W or Kres = Kdrag x 30.
Revolution per minute
RPM wheel = (v x 60) / (2 x  x rwheel,
RPMwheel x Ratiogear x Ratiodifferential
Engine torque
Engine force to move vehicle
26
2.) Force = mass × acceleration
t
Car speed
Total force
Figure 3: Simulation Result of PI Controller
3) Phase-two
Mathematical Modeling
Various steps are followed
1.) Car speed = Integral of acceleration
Tengine = Torque (max) x Throttle
[T engine x Ratio (gear + differentail)] / (rwheel)
Table 1: Mathematical Formulae
TechTalk@KPIT, Volume 8, Issue 4, 2015
Substituting equation 2 in equation 1,
3.) Total force = Engine force – Aerodynamic
drag – Rolling resistance.
F (t) = Fengine (t) – Fdrag (t) – Fres (t)
4) Aerodynamic Drag Force
Aerodynamic drag is the force acting on the
vehicle in opposite direction due to pressure
and shear stresses on its surface. It is most
evident in high speed vehicles and can be
calculated using the equation:
Fdrag (t) = Kdrag × v^2(t) = ½
×p×Cd×A×v^2(t)
Scope
Where:
P = is the air density, approximately 1.2
kg/m^3,
Cd is drag coefficient, approximately 0.32,
Frontal area, approximately 2.2 m^2.
Hence, Kdrag = 0.5×1.2×0.32×2.2 = 0.4224.
uv
1
speed [m/s]
0.4224
The final drive ratio determines the ratio of
how many revolutions the driveshaft makes to
turn the rear differential or tires one turn.
Assume Kfinal = 3.733 i.e. for every 3.733
turns of the driveshaft, the rear wheel
completes one full turn.
Gear ratio× Final ratio = Gear and differential
ratio. This converts vehicle speed to engine
RPM i.e. rotation speed of the wheel and also
converts engine torque to vehicle speed.
1
drag [N]
2
if(u1<39)
Figure 4: Aerodynamic Drag Model
5) Rolling Resistance
Rolling resistance or rolling friction or rolling
drag is a force that resists the motion when the
body rolls on a surface. It can be expressed as:
Fr = c×W,
c = rolling resistance coefficient.
W = m×g where m is the mass in kg and g is
gravity 9.81 m/s^2.
Assume c = 0.03 for a car tire rolling on tar.
Then Fr = 0.03 × 1360 × 9.81 = 400 N.
OR
We can assume that, when the vehicle travels
at approx 30 m/s (100 km/hr), rolling
resistance and drag are equal, hence we can
write:
Fres = Kres × 30,
Fdrag = Kdrag ×30^2,
Since Fres = Fdrag,
Kres × 30 = Kdrag ×30 × 30,
Hence, Kres = 30 × 0.4224 = 12.6720.
1
speed [m/s]
12.6720
Gain
1
roling res. [N]
if { } Gear 1
1
elseif(u1<60)
Gear
elseif { } Gear 2
elseif(u1<86)
3.6
1
speed [m/s]
u1
from [m/s]
to km/h
elseif { } Gear 3
Merge
elseif(u1<110)
+
1
Gear
1
2
3
4
5
6
Speed Range [km/hr]
Gear Ratio
<40
3.500
39-50
2.235
60-86
1.520
86-109
1.156
110-129
0.971
>=130
0.818
Table 2: Gear Ratio, Speed Data
1
G&D ratio
-
elseif { } Gear 5
Gear ratio
Final ratio
else
If
else { } Gear 6
Merge
Figure 6: Model of a Simple Gear Box to Select Gear
and Differential Ratio
7) Rotation Speed of The Wheel in
Revolution Per Minute (RPM)
Engine and wheel are coupled with each other
through gear box and differential.
The mathematical formulae for RPMwheel
and RPMengine are as follows:
RPMwheel = (v × 60) / (2× rwheel)
RPMengine = RPMwheel × Ratiogear ×
Ratiodifferential
RPMengine = RPMwheel × Ratio (g+d).
Assumptions made in this: wheel rim diameter
= 0.4318 m, tire height = 83.3 mm = 0.0833 m.
WheelRadius = (0.4318/2) + 0.0833 = 0.2992.
60
×
2*po*0.2992
÷
1
Speed [m/s]
×
1
Engine RPM
Divide
Figure 5: Model to Calculate Rolling Resistance
6) Engine Force
Crankshaft is located in the engine which
converts the force produced by the engine
piston into a force which helps to move the
wheel of the vehicle into circular motion so
that car can move forward. During this
phenomenon the rotation of wheel is reduced
twice, first in the gear box, where
reduction ratio can be changed by up
shifting/downshifting and then in the
differential which has fixed reduction ratio.
Now next step is to build automatic gear box.
The following data is collected through web
research survey for car:
1-D T[k]
3.7330
elseif { } Gear 4
elseif(u1<130)
Product
2
G&D Ratio
Figure 7: Model to Calculate Engine RPM
8) Engine Torque
Engine torque (Tengine) = Torque (max) ×
Throttle. The following data is assumed
through lug curve for car data.
RPM 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500 7000
Tmax 200 220 242 258 260 261 268 285 300 296 290 250 220
Table 3: Engine Torque Data
1-D T (u)
1
Engine RPM
1-D Lookup
Table
×
1
Engine Torque [Nm]
2
Throttle [0.1]
Product
Figure 8: Model to Determine Engine Torque
27
TechTalk@KPIT, Volume 8, Issue 4, 2015
9) Torque to Force
Engine torque is converted into force (F)
required to move the vehicle. We also know
the same Force (F) will be applied by the wheel
on the ground
III. Conclusion
In this article, we have designed a simple
cruise controller using MATLAB application
which helps the vehicle keep going straight in
a driving lane. Various environmental
conditions like aerodynamic drag, rolling
resistance and engine force which might affect
the vehicle speed are also calculated. Finally
we saw an abstracted model to display the
most powerful feature of MBD based design.
Twheel = F × rwheel.
Twheel = Tengine × Ratio (g+d),
Hence F × rwheel = Tengine × Ratio (g+d).
Hence F = [Tengine × Ratio (g+d) ] / (rwheel)
where rwheel = 0.992
References
[1] B.Schatz.et.al, Model Based Development of
embedded system, The Technische Universität
München, Germany.
1
Engine Torque [Nm]
×
×
2
[2] DingyuXue, YangQuan Chen, and Derek P.
1
G&D Ratio
Wheel Radius
Engine force [N]
÷
Atherton, Linear Feedback Control, Chapter 6,
Page no 184.
Figure 9: Model to Determine Engine Torque
The overall abstracted model will look as follows.
[3] P M V Subbarao Professor Mechanical
engineering department, IIT Delhi, Design of I.C.
Engine, Components & Sub-systems available at
http://web.iitd.ac.in/~pmvs/course_mel713.php
[4] Survey data available
athttp://www.engineeringtoolbox.com/rollingfriction-resistance-d_1303.html
[Throttle]
[Target]
Gear
[Gear]
RPM
[RPM]
Speed [km/h]
[Speed]
Target speed [km/h]
Throttle [0..1]
Throttle [0..1]
Vehicle speed [km/h]
Crulse controler
a. http://en.wikipedia.org/wiki/Alfa_Romeo_147
b. http://www.auto
data.net/en/?f=showCar&car_id=1319
Sample Car
Figure 10: Model of Simple Cruise Control
c. http://www.thevettenet.com/corvette_specs.php?
The simulation result is as shown below:
year=2004
d. http://en.wikipedia.org/wiki/Gear_ratio
150
Target
Speed
100
e. http://www.epieng.com/piston_engine_
50
0
technology/power_and_torque.htm
Throttle
1
08
06
04
02
Throttle
f.
http://www.epieng.com/piston_engine_
technology/power_and_torque.htm
0
RPM
500
400
300
200
100
RPM
[5] MBD tutorial available at
http://in.mathworks.com/model-based-design/
0
Gear
6
5
4
3
2
10
28
Gear
5
10
15
20
25
30
35
Figure 11: Simulation Result
TechTalk@KPIT, Volume 8, Issue 4, 2015
40
45
50
29
TechTalk@KPIT, Volume 8, Issue 4, 2015
30
TechTalk@KPIT, Volume 8, Issue 4, 2015
Modeling Aspects of
Two Wheeler Dynamics
About the Author
Vishal Pillai
Areas of Interest
Vehicle Dynamics,
Structures for Automotive and
Mechanical Engineering
31
TechTalk@KPIT, Volume 8, Issue 4, 2015
I. Abstract
Two wheeler vehicles have evolved as a mode
of transport predominantly in developing
economies. They have been used as an
alternative to three and four wheeled vehicles
due to affordability. However, these vehicles
have proven to be accident-prone due to their
inherent instability while in motion. Individual
expertise also plays an important role in riding
a two wheeler. This article focuses on
modeling the dynamics of two wheeled
vehicles and discusses the challenges in
considering the involved forces while
modeling the dynamics. It highlights
interaction between human and vehicle in
directly coupled and indirectly coupled
scenarios. It concludes on the note that there
is an important need for the current models of
two wheeled vehicles to have a self-balancing
system, and proposed a model of a selfbalancing two-wheeled vehicle.
II. Introduction to Model based
Development in Two wheeled
Vehicles
Two wheeled vehicles are known to have
drawbacks like several lightly damped modes,
wheel wobble and weave. These are steering
frequency oscillations of the system. Weave is
known to happen in case of combination of low
steering frequency at high speed. Wobble on
the other hand happens in high steering
frequency at lower speeds. Model based
development of two wheelers has been
researched by many [5] as a means to study
two wheeler dynamics. The first two wheeled
bicycle model was developed by Whipple, and
this bicycle was represented by two bodies
linked via steering mechanism. Here onwards
the improvements in the models were made
for bringing it near to the actual phenomenon.
The area of self-stabilized vehicles [4] is also
an important field considering the reduction in
accidents. Models like C1 [4] that are under
development have the potential to change the
accident-prone perception of two wheelers.
32
(a) Principles of Model based development
of two wheeled vehicles:
The following principles of dynamics have
been used for developing the model for a two
wheeled vehicle
 Jourdain's Principle
 Newton-Euler Approach
 Lagrangian Approach
TechTalk@KPIT, Volume 8, Issue 4, 2015
(b) Consideration of parameters for
modeling dynamics of two wheeled
vehicles:
Forces acting on the two-wheeler are
aerodynamic drag on the frontal area and
frictional force on the wheels.
Aerodynamic drag force is related to the
projected area of the front of the vehicle,
effected by the wind. The cross flow of air
through wheels also needs to be considered.
Wind velocity has two components; tangential
and normal to the direction of travel, which
need to be considered. The yaw angle of the
two wheeler is used to select the area for drag.
1) Frictional forces are wheel-rolling
resistance, which on the other hand is related
to the weight of the vehicle and rider, tire
pressure, road conditions and tread types.
Frictional losses in wheel bearings, frictional
losses in drive, changes in potential energy
during climbing uphill or rolling downhill, etc.
are all either modeled using Physics based
dynamic equations or data driven techniques.
2) In current modeling trends, modeling
software's, in which physical systems can be
reduced to mathematical equations, such as
MATLAB /SIMULINK, CARSIM, AMESim etc.
are normally used for simulating the dynamics
for physical systems. The code so developed
for each subsystem can be run on different
parameter inputs and conditions, without the
need to build the hardware prototype. This
results in reduction in time, cost, number of
experiments, and easy replication of code to
simulate different scenarios.
For modeling a two wheeler system which is
self-balancing, we need to understand the
governing principles of its dynamics which are
discussed below.
There can be two cases of interaction between
driver and the vehicle. The first case is of a
directly driven vehicle (by driver). The second
case is that of a vehicle which is commanded
by a driver but operates based on its additional
intelligent logic.
III. Interactions in Case of Directly
Coupled Two Wheeler System
Before analyzing the interaction between
driver and system in detail it is essential to
understand the basic mechanism of achieving
balance and motion in a simple two wheeled
vehicle such as a bicycle
Revolute Joint
Travel Direction
Frame with
Back wheel
Steering Axis
Steering rotates
towards right
R
R
0.6R
Steering head
angle
0.15R
Ground Line
Intersection
Point
Trail
Figure 1. Geometry of a Bicycle
Vehicle tilted
towards right
(a) Steering Geometry
The steering and the front wheel are always
mounted in such a way that the wheel's point
of contact with the ground is behind the point
where the steering axis would intersect the
ground. This is called the trail. Also, the
intersection point of steering axis and vertical
line through the center of the wheel should lie
in a tolerance of 0.15 to 0.6 times the radius of
the wheel. (Fig. 1) .This ensures that steering
head angle results in a force directly on the
front wheel (from the ground) which will turn it
towards the direction of vehicle tilt. This
geometry ensures stability.
(b) Operator Skill
A two wheeled vehicle can be balanced by the
operator by actuating the steering. When
operator steers the bike such that the wheels
are directly below the center of gravity (cg),
then the bike is balanced even when not in
considerable motion (slow cycling). When in
motion (lesser speeds), consider a case
when the bike and operator tilts to one side,
and the operator rotates the steering handle
wherein one arm pushes and the other pulls
the handle bar towards the direction of fall.
This causes the shifted cg to result in altered
weight component to counterbalance the
vehicles lateral motion and hence restores
balance (Fig.2) [3].
Balanced motion
Imbalance towards right
Impulse by rider to
steer vehicle as shown
Figure 2. Interaction Between Driver and the Bicycle
Tilt of a two wheeler in motion
F  M.
v2
cosθ
r
H
Centripetal force F  M.
v2
r
θ
θ
θ
F  M .g sin 
F  M .g
Figure 3 Tilt of a Two Wheeler in Motion
Consider a two wheeler taking a turn towards
right and at a tilt ɵ from the vertical plane. The
vertical force which acts on it is the weight of
the vehicle, which is counterbalanced by
reaction forces on wheels. In Fig. 3, V is the
tangential velocity and r is the radius of
curvature. It shows the tilt angle ɵ, which is
by resolving centrifugal and weight
component forces, where centripetal
acceleration
to have equilibrium
condition. The appropriate tilt is the result of
counter steering which is instrumental in
achieving balance.
(d) Interaction mechanisms in indirectly
coupled two wheeler system
These are :
1) Mechanism of Control moment
gyroscope.
In case of design of a two-wheeler system
equipped with additional intelligent logic and a
gyroscope for stability, it is important to
understand the mechanism of gyroscopic
motion.
H
H

θ
M
Mc + Md
l
C
C
g
g
l
Wheel base
Figure 4. Moments Acting on a Two Wheeled Vehicle
Consider a two wheeled vehicle as shown in
Fig 4. The vehicle model has a steering
mechanism, a front wheel, body, and a rear
wheel. For simplicity, we consider a four-body
mechanism of two-wheeler.
Let the cg of the vehicle be at a distance l from
the ground. There is a gyroscope disc
mounted on the vehicle having precession
axis H. The axis H is normally vertical when
there is no tilt of the vehicle. Consider that we
are able to change the axis of precision in fore
and aft direction by an actuating mechanism
attached to the gyro disc providing a moment
This causes a reaction moment
which can
be used as a tilt control moment
for
stabilization. Alternatively, if there is a tilt
motion can be ignored. This explains how a
control moment gyroscope can
be
employed to control stability of a two wheeler
2) Interaction between operator and
vehicle in indirectly coupled system
The examples of an uncoupled system is the
kind of vehicle being developed by Lit
Motors[4], the self-stabilizing vehicle in which
gyroscopic systems have been incorporated
using electric drive systems consisting of
motor and generators. A flywheel disc which
rotates at an angular velocity
produces enough moment (M) to
stabilize the vehicle.
33
TechTalk@KPIT, Volume 8, Issue 4, 2015
Where
can be changed to compensate
for load variations and
is the tilt's angular
velocity that is being driven by a motor to
provide appropriate tilt. In this system, the
interaction between operator and vehicle is
through a drive by wire steering mechanism
which takes in the input from the driver action
and processes it to actuate the motor for
appropriate motion. So, the steering input is
decoupled as compared to a non-selfbalancing two wheeler system. The desired tilt
of the vehicle is computed by the system at all
times. When this tilt is compared with the
actual sensed tilt, the resulting discrepancy is
fed as a control input to the vehicle gyro tilt
angular velocity controller which in turn
actuates the motor (orthogonal to flywheel
axis) to provide appropriate tilt for stability.
There are existing accelerometers which work
in closed loop providing speed control of the
flywheel to maintain stability of the vehicle.
Figure 6 illustrates through block diagrams the
closed loop control system as discussed.
Further, Figure. 7 shows the control moment
gyroscope (in operation), developed for C1 by
Lit Motors [6].
Vehicle Body
Sensors
Processors
Flywheel Sensors
(Tilt angle and velocity)
Inertia Sensors (Rotation
and acceleration)
Current state Sensors (Tilt,
GPS)
Controls
Flywheel
speed
Several aspects of the dynamic stability of a
two wheeler vehicle along with their basic
principles have been discussed. Further, a
specific case example considering gyroscope
and associated controllers for stability is
analyzed to understand the mechanism
leading to the achievement of self-balancing
operation. The amount of complexities and
analysis required to consider controller
operation and the dynamics for the selfbalancing two wheeler dictates a need for
Model Based Design which can be an exciting
field of research.
It gives an opportunity to have an aftermarket
system which can cater to the existing lot of
non-stabilized two wheelers on the road. This
is an area where practical work is yet to be
witnessed.
References
[1] Journal of Applied Biomechanics 1998. Validation
of a Mathematical model for road cycling power.
James C. Martin, Douglas L. Mikkiken,John E.
Cobb, Kelvin L.Mc Fadden and Andrew R.
Coggan.
[2] Vehicle system Dynamics, 2002, vol 37 no.2pp
145- 156.Tilt control for Gyro-Stabilized Two
wheeler vehicles. Dean Karnopp.
Inputs
Vehicle speed,
brake, acceleration,
steering inputs
IV. Conclusion
Flywheel
tilt angle
Figure 5. Closed Loop Control System for Self-balancing
[3] Vehicle System Dynamics, Taylor & Francis: STM,
Behavioral Science and Public Health Titles,
2013, 51 (5), pp.648- 670.
<10.1080/00423114.2012.762536>. <hal00786265>Lamri Nehaoua, Hichem Arioui,
Nicolas Seguy, Said Mammar. Dynamic modelling
of a two-wheeled vehicle: Jourdain formalism.
[4] US Patent US8532915B2, Electronic control
system for gyroscopic stabilized vehicle. Daniel
Kee Young Kim, Kelvin Bretney, Andrew Shao,
Andrew L.Tsang.
[5] The control and stability analysis of two wheeler
vehicles, thesis submitted by Simos Evangelou,
Electrical and Electronic Engineering Imperial
College London.
34
Figure 6. Control Moment Gyroscope Used in
C1 Developed by Lit Motors.
TechTalk@KPIT, Volume 8, Issue 4, 2015
[6] Development of the self-balancing vehicle by Lit
Motors: http://litmotors.com/c1/
35
TechTalk@KPIT, Volume 8, Issue 4, 2015
36
TechTalk@KPIT, Volume 8, Issue 4, 2015
Best Practices for
Model Based Designing
in Automotive Industry
About the Authors
Pallavi Kalyanasundaram
Areas of Interest
Embedded System Design,
Model Based Design
Varsha S. Pathak
Areas of Interest
Embedded firmware development,
Automation, Automotive embedded design
37
TechTalk@KPIT, Volume 8, Issue 4, 2015
components, for testing and model simulation,
popular as Model in loop (MIL) testing.
Model Based Development (MBD) has shown
2) Different MBD tools are used at different
immense potential in dealing with the
stages of application development. Figure 2
increasing design complexities related to the
tries to capture the popular tools used by the
development of modern automotive systems.
top automotive companies. The tool names
As a result, MBD has become an
are followed by their manufacturers and are
indispensable part of application development
represented
with reference to the V model as
i n t h e a u t o m o t i v e i n d u s t r y t o d a y.
shown
in
Figure
2.
Subsequently, it becomes extremely essential
to have a strong understanding about the
Model Examiner(MES),
accepted procedures, guidelines, and
UML(OMG),
Polyspace Code Prover,
Validation &
SySML(OMG),
MATLAB, Simulink
benchmarks related to MBD. It is always Requirements
(Mathworks), BTC
Simulink(Mathworks),
Analysis
Verification
Embedded validator
Target Link(Dspace),
important to be updated with the current trends
(BTC)
and standards of a paradigm or technology of
Matlab(Mathworks),
Reactis, BTC Embedded
Simulink(Mathworks),
Tester, Specifier(BTC),
interest. Hence, the further sections talk about
System
Labview (NI),
TPT(PikeTec GmbH),
MES
M-Xray
(MES),
Stateflow(Mathworks),
Design
Testing
the best practices in the automotive industry
Adams (MSC), SimDriveline
Mtest(MES), MaTeLo
with respect to MBD incorporation and
development of new MBD tools. The practices
Embedded
Coder(Mathworks),
Code
elaborated are results of studying the MBD
Simulink Coder
Design
(Mathworks)
environments adopted by leading automotive
manufacturers.
Figure 2: Popular MBD Tools Used by Major Automotive Industries
I. Introduction
V-model
II. Practices
To address the best practices followed, the
MBD process can be categorized into five
different aspects as highlighted in Figure 1 [1].
The dotted lines in Figure 1 indicate the
dependency of each aspect on one another.
Broadly, these aspects can be classified into
technical (Technology and Technical) and
non-technical (Business, Management and
Organizational) categories as discussed in the
later sections.
Technology Context
Business Context
Organizational Context
MBD
Aspects
Management Process
38
Technical Process
Figure 1: MBD Aspects [1]
(a) Technical Aspects:
This section attempts to briefly cover the
outline of MBD practices based on the
technical front.
1) J. Hutchinson et al. [2] explore various MBD
activities practiced across industries which
include use of models for the following tasks:
Understanding a problem at abstract level
before starting any new development, for team
communication, to capture and document the
design, for automatic code generation (target
specific or generic), for model to model
transformation, use of Domain Specific
Languages (DSLs) which favors reusability of
TechTalk@KPIT, Volume 8, Issue 4, 2015
1) There are various standards and guidelines
to which the automotive applications must
adhere. Some of the major ones are
mentioned below:
(a) IEC 61508: IEC 61508 is the international
standard to provide the required safety
integrity level.
(b) ISO/DIS26262: ISO 26262 is a functional
safety standard containing detailed guidance
on software tool qualification.
(c) MISRA-C: MISRA C is a formal set of
guidelines to identify aspects of the C
language that should be avoided due to their
ambiguity and susceptibility to common
programming mistakes.
(d) The MathWorks Automotive Advisory
Board (MAAB): The MAAB is an independent
board that develops guidelines for using
MATLAB®, Simulink®, State flow® and
Embedded Coder®.
2) MBD design demands sound domain
knowledge, good abstraction, and
programming skills.
3) The success of MBD relies on its design
more than implementation.
Technical aspects are just one side of the coin,
which do not suffice the requirement of
understanding the whole MBD process. Nontechnical aspects need to go hand-in-hand
with its technical counterpart to achieve the
intended target.
(a) Non-Technical Aspects:
J. Hutchinson et al. [2] identify that complex
organizational, managerial and social factors
influence the relative success or failure of
MBD practices. Following are some of the
practices incorporated pertaining to the nontechnical aspects of MBD.
1) Set Goal for MBD - The organization needs
to have a clear picture about why to opt for
MBD. Organizations need to evaluate weak
points in their development processes and
identify problems to be tackled first.
2) Keep a long-term vision - Migration from
traditional process to Model Based design is
time consuming. Moreover, the initial
switching investment is huge. Long-term
vision is crucial to enjoy benefits in the long
run.
3) Integration with existing process - While
incorporating MBD, existing processes and
metrics need to be analyzed and modified.
Guidelines need to be reviewed, developed,
and enforced at different phases.
4) Collaboration with tool suppliers Organizations willing to adopt MBD may
consider their tool partners as sole supporters.
Since tool manufactures bring their
experience, they can help to avoid common
pitfalls, accelerate adaptation of tools and
environment, increase return on investments,
etc. They can help better in achieving goals.
5) Engineering teams - An MBD engineer must
possess good abstraction skills and domain
knowledge. Additionally, programming
expertise cannot be ignored. It becomes
difficult to train engineers for all these skills.
Hence, the design and development teams
should have a mix of engineers highly trained
in one of the three skills.
6) Resource assignment - Management must
take decision to select strong, experienced,
highly reliable person who has proven record
of accomplishment to adapt this platform.
The success of MBD practice in an
organization depends on how the organization
strikes a perfect balance between the
technical and non-technical aspects. As a next
step, to sustain in the competitive market,
automotive manufacturers are working on
smoothening their MBD process by building
new tools. The next section puts light on the
same.
III. MBD Tools
As MBD is still an emerging field, lot of work
related to development of new MBD tools is
undertaken. If we consider the MBD process,
the main gist with respect to development of
new tools lies in the automatic conversion of
the input models to either code, model or text
depending upon the application area. The
various disciplines witnessing the arrival of
new tools along with the already existing ones
are taken into consideration.
Model
Conversion
Code
Model
Text
Figure 3. Gist of MBD for New Tool Development
(a) MBD tools - Current trends and Future:
It is astonishing to see the areas where MBD
tools have evolved in the last few years. The
MBD practitioners have left no stone
unturned. The following points give a glimpse
of the same. It also tries to explore new
spheres for MBD tool development.
1) Tools are developed for Model to Model
Conversion
(a) Stürmer et al. [4] talk about identifying and
modifying the input model (called refactoring
the model) with respect to violation of MAAB
guidelines.
2) Tools for Model to text conversion
(a) This includes generation of validation
report after model simulation
3) Model to code generation tools
(a) Many tools already exist e.g. Embedded
Coder. The code generated is targeted for a
specific platform or can be generic. New
platforms will demand redesigning the existing
tools or need to develop newer ones.
4) Auto-generated code validation tools
(a) Tools to check code compliance to
software standards. E.g. MISRA C guidelines
and standards
(b) Tools for verifying the functionality of autogenerated code
5) Tools for Validation of models
(a) Tools for checking the standards and
guidelines, which should be met by the models
(b)Test pattern generation tools for models
(c) Validation report for models
(d) Volkswagen also focuses on interface
quality optimization related to MBD. It has
developed a tool integrated with the MES
(Expand) Model Examiner for verification of
interface definitions often documented in
excel spreadsheets [5].
6) Designing bi-directional tools e.g. a single
tool, which converts code to model and viceversa
7) Code to Model Conversion tools [6]
8) Tools to automatically generate models
based on the requirement text file (Text to
Model conversion)
9) A tool, which provides the flexibility to
choose or combine DSLs, will serve a great
purpose, as embedded automotive systems
are highly interdisciplinary. There can be a
requirement to use multiple domains (more
specifically DSL) in a single application and
39
TechTalk@KPIT, Volume 8, Issue 4, 2015
produce the output.
10) Equivalence checking between code and
its corresponding model [7]
The quest for exploring new dimensions in
MBD cannot be curtailed. Therefore, it is
necessary to follow a systematic approach
while developing new tools in order to
increase their shelf life. Some of the points that
should not be ignored while designing new
tools are explained below.
(a) Practices considered while developing
new MBD tools:
1) The requirements and the scope of the tool
should be properly defined
2) Long-term vision for the tool to be
developed
3) Tools are modular enough so that its
components are reusable
4) Interface quality between components [5]
5) Integrating the existing tools with the newer
ones to reduce the development time (Facility
as a new plugin to the tool)
6) Reusing the legacy components to
maximum extent for the development of new
tools
7) Using existing platforms for model
transformation:
(a) Eclipse modeling framework (EMF) is
widely used. It is a platform provided by
Eclipse for auto code generation. It is a
framework used to develop tools and models.
(b) There are many model transformation
languages available like ATL (ATLAS
Transformation Language), QVT
(Query/View/Transformation) etc.
verge of replacing traditional software
application development methods.
References
[1] Navet, Nicolas, and Françoise Simonot-Lion, eds.
Automotive embedded systems handbook. CRC
press, 2008.
[2] Hutchinson, John, Jon Whittle, and Mark
Rouncefield. "Model-driven engineering practices
in industry: Social, organizational and managerial
factors that lead to success or failure." Science of
Computer Programming 89 (2014): 144-161.
[3] Smith, Paul F., Sameer M. Prabhu, and Jonathon
Friedman. Best practices for establishing a modelbased design culture. No. 2007-01-0777. SAE
Technical Paper, 2007.
[4] Stürmer, Ingo, Christian Dziobek, and Hartmut
Pohlheim. "Modeling Guidelines and Model
Analysis Tools in Embedded Automotive Software
Development." MBEES. 2008.
[5] http://www.modelengineers.com/files/content/press/2014/20140318
_News_VW_Schnittstellen_EN_FINAL.pdf
[6] Palakkal, Smitha Kizhakkae, et al. "Automatic C to
Simulink Model Converter (C2M) Tool." SAE
IV. Conclusion:
Model based development process is highly
interdisciplinary when it comes to automotive
system development. Therefore, the practices
followed across different automotive industries
vary significantly. Moreover, within an
organization, the practices may need timely
restructuring to welcome newer technologies,
which are blooming at lightning speeds. The
near future will witness emergence of new
tools for bridging the gaps in MBD with a vision
to automate the complete application
development process. MBD is truly on the
40
TechTalk@KPIT, Volume 8, Issue 4, 2015
International Journal of Passenger Cars-Electronic
and Electrical Systems 8.2015-01-0164 (2015).
[7] http://cmacs.cs.cmu.edu/presentations/verif_
csystems/06_KenButts.pdf
41
TechTalk@KPIT, Volume 8, Issue 4, 2015
Design and
Development of Muffler
About the Authors
Vicky Choudhari
Area of Interest
After-Treatment systems (Emissions)
Priyank Vijapur
Area of Interest
I C Engine, Emissions
42
TechTalk@KPIT, Volume 8, Issue 4, 2015
I. Introduction
 application of engine,
We all know that, unpleasant sound is known
as “Noise”. Threshold hearing capacity of
human is 70dB. Sound intensity level of 85 dB
or higher can be fatal and cause permanent
damage to hearing. Around 22% to 30% noise
is contributed by engine alone, while exhaust
system which contributes 22% to 35%. Petrol
a n d D i e s e l e n g i n e w i t h o u t m u ff l e r
approximately produce noise in the range of 90
to 100 dB and 100 to 125 dB respectively.
Mufflers help to attenuate engine noise.
Therefore, design and development of
muffler/exhaust system has gained prime
importance.
 engine capacity, engine speed, engine
Mufflers are categorized on the basis of noise
reduction methods.
 Reactive /Reflective: - Fig.1 shows a
Reactive/Reflective type of muffler having
different resonating and expansion chambers
to attenuate the sound intensity. Sound energy
is reflected back towards the noise source.
Sound wave produced in engine partially
cancels themselves in muffler. Phenomenon
of destructive interference is used to reduce
noise. For complete destructive interference to
occur a reflected pressure wave of equal
magnitude and 180 degrees out of phase
needs to collide with transmitted pressure
wave. [2]
 Absorptive/dissipative: - Fig.2 shows
Absorptive/Dissipative type of muffler.
Thermo-acoustic materials like mineral wool,
fiberglass, sintered metal composites and
white wool are used to absorb high frequency
sound waves. Sound energy is converted to a
very small amount of heat energy. Absorptive
material is wound on perforated tubes and
these are inserted inside large casing. [2]
power output,
 mountings and packaging requirement,
 Mass flow rate of exhaust gases, fluid
pressure and temperature,
 allowable pressure drop
 Noise intensity without muffler and the
attenuation required.
2) Design Calculation
Designing a muffler is an iterative method. To
begin with, analytical design calculation
process is followed to determine volume and
shape of exhaust system. Engine size,
packaging requirement, feasibility etc. are
considered in this phase. Backpressure for
various geometries and internal
configurations are determined as it directly
affects efficiency and fuel consumption.
Sound intensity can be calculated analytically
for different internal configurations.
Depending upon the application of engine and
size, we decide the shape of the muffler; for
example, Circular, Elliptical, Rectangular or
duct shape. Following are the formulae to
calculate the volume of muffler.[2]
Engine Firing Rate (EFR) =
Acoustic Length (L)
Speed of sound (Vs) = 331.6 m/s
Vs varies with temperature =
Length of muffler can be calculated, which is
generally a varying factor, as we always have
defined space constraints for mounting.
To cope with the problem of backpressure,
muffler volume should be larger than the
volume of engine. Hence, we consider a size
factor, which varies from 12 to 25. Multiplying
this factor to engine volume, we get volume of
muffler.
Volume of muffler = engine volume * size
Figure 1: Reactive/Reflective Type Figure 2: Absorptive/Dissipative Typefactor ……. (iv)
Let's consider our muffler is of circular shape
II. Factors Involved in Design and
having
diameter (D)
Development of an Exhaust
System
1) Vehicle/ Engine Specification
43
While designing a muffler, major parameters
are need to be known, such as, a
TechTalk@KPIT, Volume 8, Issue 4, 2015
Volume of Muffler =
Length and Diameter of a circular shape
muffler can be calculated using equations (ii),
(v)
Perforated Pipes:
The diameter of hole (d) to be drilled/punched
on the pipe is calculated by thumb rule given
below,
Figure 4:
Muffler Assembly with
4 chambers
Figure 5:
Muffler Assembly with
3 Chambers
4) Structural Analysis
While designing a perforated pipe as shown in
Fig. 3, porosity needs to be considered, since
lesser the porosity more is the restriction and
more will be the backpressure. Porosity can
be calculated by using following formula,
Where,
N= Engine speed in rpm,
l = length of perforated pipe,
C= Centre to centre distance between two
holes horizontally and vertically.
Analytical calculations act as references,
rather they gives us a start point to design a
product. Calculated dimensions are used to
make a 3D model using CAD modelling
software's.
Static and Dynamic analysis are performed to
study the behaviour of system at different
loading conditions. Finite Element Analysis
(FEA) is used to study the structural strength
and predict reasons for failure. Structural
analysis will let us know whether the system
meets the design acceptance criteria.. Hot
exhaust gases generate thermal stresses in
the muffler assembly, so the impact of the
generated thermal stresses is also studied in
structural analysis. Computer Aided
Engineering (CAE) is used to analyse the
mountings, weld fatigue and strength of
exhaust system.[1]
 Vibrational Analysis
The exhaust system receives vibration from
engine and then transfers to the body
structure through hanger. Hence, it is very
important to study the dynamic characteristics
 Static, Modal and Dynamic analysis
Stresses occurring along the structure are
analysed in static analysis. Boundary
conditions are defined as per the loads
actually occurring on the component (fig. 6a).
Figure 3: Perforated Pipe
3)
Computer Aided Design (CAD
Modelling)
CAD model is a 3D model of a component.
CAD tool allows us to make 3D as well as
drawing of each assembly and its
components. This drawing is used at the time
of manufacturing and assembling the
components.
Based on calculations of muffler volume and
considering the effect of backpressure, CAD
model is designed using CAD tool. Fig. 4 and 5
shows two concepts generated in CAD tool.
Further, this model is sent for simulation,
where the analysis of whole system is done.
Frequencies occurring as per the mass,
stiffness and degrees of freedom given to the
component is measured in Modal analysis (as
shown in fig. 6b).
To measure the fatigue, random vibrations
and harmonics, dynamic analysis is carried
out on the structure. Weld fatigue can also be
measured here (fig. 6c).
System is considered as a spring, mass and
damper system
Where, [M], [C] and [K] are mass matrix,
damping matrix and stiffness matrix respectively.
Figure 6a: Static analysis
44
TechTalk@KPIT, Volume 8, Issue 4, 2015
configurations, so the results obtained for
different configurations and modifications can
be measured using flow analysis.
Figure 6b: Modal analysis
Figure 6c: Fatigue life
5) Flow Analysis
Muffler deals with the flow of hot exhaust
gases, which are highly turbulent, also
mufflers are designed to reduce the noise
without affecting backpressure. To reduce
noise, muffler is made up of different
resonating chambers, these chambers act as
an obstruction to the flow of gases, which
creates a backpressure. All this effects are
studied in Flow Analysis.
Figure 7: Exhaust gas flow (m/s)
Flow analysis is also used to study the “Mixing
Phenomena” during the flow (in case of
Selective Catalytic Reduction (SCR) etc.).
Figure 9a: Chamber 1
Figure 9b: Chamber 2
6) System Level Analysis
Performance of muffler when assembled with
engine is analysed using 1D simulation
software. All the data related with
performance of muffler that can affect engine
performance is collected, for instance back
pressure, noise, effects on power output of
engine. If the measured data meets the
criteria, we move further for physical testing,
else, design is further optimized. [8]
Fig.10a & 10b shows Acoustics simulation
with full engine model capturing exhaust
acoustic characteristics.
Following parameters are validated:
- Transmission loss
- Insertion loss
- Acoustic sound pressure level
Figure 8: Total Pressure exerted
45
Computational Fluid Dynamics (CFD) is a
branch of fluid dynamics, which deals with the
problem involving flowing fluid and solves
those problems using numerical methods and
algorithms to study and analyse the flow of
fluid and its effect on system. Fig. 8 shows
computational results that the pressure drop is
derived from the sudden reduction and
sudden expansion in the baffle plates and
perforated tubes, which forms chambers and
depends on the variation of flow direction.
Fig.7 & 8 show the results of flow analysis,
pressure drop along the component, velocity
vector, streamlines or flow path. In the design
phase, mufflers are made of different internal
TechTalk@KPIT, Volume 8, Issue 4, 2015
Figure 10a: Simulation Window
Figure 10b: Engine speed vs. Backpressure
7) Physical Testing
Here physical model is made and subjected to
actual conditions of loading. Actual data is
compared with the data obtained from
simulation. Along with the strength tests, other
tests such as leakage, rattle, and
measurement of transmission loss, insertion
loss, and noise reduction are also done here.
a) Leakage Test :
Leakage test ensures that system is not
leaked at joints or from exhaust assembly
parts. Complete assembly of muffler is fixed
on a fixture and the flow of gases at the exit of
muffler is blocked. Entire system is subjected
to some internal pressure for a specific period
of time. Exhaust system should meet the
defined drawing test specification.
b) Backpressure :
A pressure transducer or manometer is
mounted across the exhaust manifold to
measure backpressure. Engine speed is
increased from idling to full throttle and
change in backpressure is measured.
Backpressure must not exceed maximum
specified backpressure. As a thumb rule, back
pressure shall not reduce the power, torque
and fuel economy intended from the engine by
more than 5%.[5]
Measurement of backpressure is done at full
load on engine for following conditions
 Engine Cold Condition.
 Engine Warm up Condition.
c) Thermal Shock Test :
The manifold end of the exhaust assembly is
connected to hot air source capable of raising
the temperature up to the temperature of hot
exhaust gas for a specific period. Test is done
for several hours with specific number of
heating and cooling cycles per hours.[6]
d) Transmission Loss Analysis:
Transmission loss is the rate of sound
pressure level at inlet and outlet of the muffler.
General methods to measure Transmission
loss are the “Two Load Method” and “Two
Source Method”. [4]
Two Load Method consists of 4 microphones,
2 microphones are placed at the inlet and
outlet of the muffler to determine both the
progressive and reflective waves.
Two Source-Location Method is an improved
method in which source is moved from inlet to
outlet location.
Figure 11: Two Load Method (a)
when outlet is open
when to atmosphere and (b)
when load at outlet is closed.[4]
Figure 12: Two Source-Location (a)
source is at inlet and (b)
when rigidly source is at outlet.[4]
Insertion Loss Analysis
Difference in the sound pressure level
measured at the same point with and without
introducing a muffler. [4]
Data obtained from simulation is compared
with the data obtained from physical testing of
model. These two data are always scattered
from each other, so we try to meet the
simulation data with the actual tested data.
The design is further optimized to get the
simulation data matching with actual data.
III) Future Scope of Work
Reduction of pressure drop due to the muffler
geometry, which will in turn reduce the fuel
consumption and increase engine efficiency,
is the final goal.
This can be achieved by introducing Thermoacoustic material in different muffler
chambers, modifying internal configuration or
varying chamber size. Operations such as
design, production cost, and optimization of
component are various tasks at hand to evolve
its functional, packaging and cost
requirement.
References
[1] “General Design principles for an Automotive Muffler”, by Potente, Daniel
[2] Paper on “Practical Approach Towards Muffler Design, Development And Prototype
Validation” by Shital Shah, Saisankaranarayana K, S. Hatti and Prof D.G Thombare
[3] “Systematic FEA Study Of Passenger Car Exhaust System” by S. Rajadurai and
N.Suresh
[4] “Muffler Characterization With Implementation Of FEM And Experimental Techniques”,
by Tyler W. Le Roy
[5] “Development Of An Automatic Design And Optimization System For Industrial Muffler”,
by Lee Ming Wong and G. Gary Wang
[6] SAE Paper no. 2003-26-0029 SIAT03 on, “A System Approach to Automotive Exhaust
System Development” by Dr. K.C. Vora, A.S. Patil and V. G. Halbe.
[7] Article on “Thermal Analysis for Motor-Bike Exhaust Silencer for Ensuring Reduction in
Hot Spots through Design Enhancement” published in International Journal of Advanced
Engineering Research and Studies.
[8] Presentation on “A Hybrid Methodology for Design and Optimization of an Exhaust
Silencer” by S.S. Ramdasi, A.V. Subbarao and N.V Marathe.
Figures
[9] Figure 1- http://gearheads.org/your-cars-mufflertuned-like-a-fine-instrument/
Figure 2- http://www.burnsstainless.com/muffler_technology_part_2.aspx
Figure 9a/9b - SAE Paper no. 2003-26-0029 SIAT03 on, “A System Approach to Automotive
Exhaust System Development” by Dr. K.C. Vora, A.S. Patil and V. G. Halbe.
Figugre 10a/10b - Presentation on “A Hybrid Methodology for Design and Optimization of
an Exhaust Silencer” by S.S. Ramdasi, A.V. Subbarao and N.V Marathe.
Figure 11/12 - “Muffler Characterization With Implementation Of FEM And Experimental
Techniques”, by Tyler W. Le Roy
[10] Fig 3, 4, 5, 6a, 6b, 6c, 7, 8 are sample modelled at KPIT especially for this article.
TechTalk@KPIT, Volume 8, Issue 4, 2015 46
About KPIT Technologies Limited
KPIT a trusted global IT consulting & product engineering partner focused
on co-innovating domain intensive technology solutions. We help
customers globalize their process and systems efficiently through a
unique blend of domain-intensive technology and process expertise. As
leaders in our space, we are singularly focused on co-creating technology
products and solutions to help our customers become efficient,
integrated, and innovative manufacturing enterprises. We have filed for
60+ patents in the areas of Automotive Technology, Hybrid Vehicles, High
Performance Computing, Driver Safety Systems, Battery Management
System, and Semiconductors.
About CREST
Center for Research in Engineering Sciences and Technology (CREST) is
focused on innovation, technology, research and development in
emerging technologies. Our vision is to build KPIT as the global leader in
selected technologies of interest, to enable free exchange of ideas, and to
create an atmosphere of innovation throughout the company. CREST is
recognized and approved R & D Center by the Dept. of Scientific and
Industrial Research, India. This journal is an endeavor to bring you the
latest in scientific research and technology.
Invitation to Write Articles
Our forthcoming issue to be released in January 2016 will be based on
“Sensor Fusion - A Need for Next Generation Automobiles”. We invite
you to share your knowledge by contributing to this journal.
Format of the Articles
Your original articles should be based on the central theme of “Sensor
Fusion - A Need for Next Generation Automobiles”. The length of the
articles should be between 1200 to 1500 words. Appropriate references
should be included at the end of the articles. All the pictures should be from
public domain and of high resolution. Please include a brief write-up and a
photograph of yourself along with the article. The last date for submission
of articles for the next issue is November 28, 2015.
To send in your contributions, please write to crest@kpit.com .
To know more about us, log on to www.kpit.com .
Innovation for customers
ISSN 2394-5397
TechTalk@KPIT October - December 2015
Ivar Jacobson
August 22, 1947
September 2, 1939
“The fact is that UML and other
modelling language are not meant
to be executable. The point of models
is that they are imprecise
and ambiguous.”
“A use case is a complete course of
events in the system,
seen from a user's perspective.”
y
James Rumbaugh
35 & 36, Rajiv Gandhi Infotech Park, Phase - 1, MIDC, Hinjewadi, Pune - 411 057, India.
For private circulation only.