GRAPHICS RENDERING, INTERFACING AND
IMPLEMENTATION OF DIALS IN
A PROJECT REPORT
Under the guidance of
Mr. GEETHANATHAN SUNDERESAN
in partial fulfillment of the requirements for the award of the
BACHELOR OF TECHNOLOGY IN
ELECTRONICS AND COMMUNICATION ENGINEERING
AMRITA SCHOOL OF ENGINEERING COIMBATORE 641112 June 2018
AMRITA VISHWA VIDYAPEETHAM
AMRITA SCHOOL OF ENGINEERING, COIMBATORE, 641112
This is to certify that the project report entitled ” Graphics rendering, interfacing
and implementation of dials in instrument clusters”.
in partial fulfillment of the requirements for the award of the Degree of Bachelor of
Technology in ELECTRONICS AND COMMUNICATION ENGINEERING is
a Bonafide record of the work carried out under our guidance and supervision at
Amrita School of Engineering, Coimbatore and Robert Bosch Business and
Engineering Solutions Private Limited (RBEI).
Internal Project Advisor External Project Advisor Project Coordinator
Mr. Sabarish Narayanan B Mr.Geethanathan Sunderesan Mr. P. Sudeesh
Asst. Professor Architect Asst. Professor
RBEI Private Limited
Dr. M. Jayakumar
The project was evaluated by us on:
Internal Examiner External Examiner
INTERNSHIP COMPLETION CERTFICATE iii
I would like to take this opportunity to express my gratitude to all the people who
have helped me in my project.
First and foremost, I would like to thank both my mentors, Mr. Geethanathan
Sunderesan , Architect, ECI department, RBEI private limited and Mr. Tony
Abraham , Senior software engineer, ECI department, RBEI private limi ted, whose
constant suggestions and encouragement have given me much insight into the pr oject
work. It has been a great privilege and joy to study under their guida nce and
supervision. Their insightful observation and effective feedback despite their busy
schedules encouraged me during the project.
I express my heartfelt gratitude to Mr. Ajith, Group manager, ECI department, RBEI
private limited, for his suggestions and encouragements towards both impr ovements in
the project work and towards career growth.
I express my heartfelt gratitude to Dr. M. Jayakumar, Chairperson, Department of
Electronics and Communication Engineering for his continued support.
I express my sincere gratitude to Ms. Priya Haikumar, Class Advisor, Mr. E.
Prabhu , Class Counsellor, Department of Electronics and Communication Enginee ring
and Ms. Rolent Gini , Assistant professor, Department of Electronics and
Communication Engineering, for their valuable support and suggestions.
I express my sincere gratitude to Mr. Sabarish Narayanan B, Assistant Professor,
Department of Electronics and Communication for his encouragement and support.
I also express my sincere thanks to
my friends and colleagues who helped me a lot in
completion of my project.
Instrument cluster is the center to all information pertaining to vehicle status, warning and other
information. It collects all related parameters from the ECU s and presents graphically to the
user/driver. It also serves as a two-way bind by not just display ing information, but also
responding to drivers’ intentions through buttons or any other Human-Machine Interface (HMI)
driver. It serves greater purpose than traditional dials and gauges because clusters can display
context-related information and can express priority and alerts be tter. Moreover, traditional dials
are meant to display only a fixed amount of information, but clusters can be more dynamic
(example, Navigation/Media can be displayed on the same display) . They can contain User
Interfaces (UI), which allows the driver to interact with the vehicle behavior and provides a
much friendlier and less-distracting method to deal with tasks whil e in-drive. The current project
involves the creation of such interface to deal with day-to-day vehic ular tasks. The project
follows MVC architecture for deciding what to be displayed, when to be displayed and how the
data shall be displayed. Implementation of the interface involves D esigning and Animation of
Clusters. The general process flows in three phases – Asset Ge neration, UI Processing Code and
Asset-Code Integration. The goal of the project is to customize the core graphics and interface
without affecting the internal processing core’s compatibility, p erformance and scalability. This
can be done with modularizing code, various optimization techniques and related concepts.
TABLE OF CONTENTS
LIST OF ABBREVIATIONS
LIST OF FIGURES
2.2.1 CAN BUS
2.3 MICROCONTROLLER 5 6 8 10 12
3.3 TECHNICAL GOALS
3.5.1 BASIC SOFTWARE
3.5.2 AUTOSAR OS
3.5.3 COMPLEX DEVICE DRIVER
3.5.4 RUN TIME ENVIRONMENT
3.5.5 APPLICATION LAYER 14 15 15 16 16 17 18 19 20 20 20
DUAL CORE CLUSTER IMPLEMENTATION
4.1 DATA ACQUISITION
4.3 GRAPHICAL PROCESSING 22 23 24 25
MVC ARCHITECTURE 27
6.1 STEPS INVLOVLED IN DESIGNING AN
6.1.1 REQUIREMENT ANALYSIS
6.1.2 SYSTEM ANALYSIS
6.1.3 MODULE DESIGN
6.1.5 TESTING AND FLASHING 32 33 33 35 35 39 41
DESIGN CHALLENGES 43
LIST OF ABBREVIATIONS
ABBREVIATION EXPANSION PAGE NO
AUTOSAR Automotive Open System Architecture 15
CAN Controller Area Network 9
ECU Electronic Control Unit 2
GPU Graphical Processing Unit 26
HMI Human Machine Interface 2
LIN Local Interconnect Network 9
MOST Media Oriented Systems Transport 9
LIST OF FIGURES
2.1 2.2 2.3 2.4 2.5
Block diagram of an instrument cluster
Block diagram of ECU
Blocks inside an ECU
System with and without CAN
6 7 7 10 11 12
Layered architecture of AUTOSAR
Detailed layered architecture of AUTOSAR
4.1 4.2 4.3
Dual core cluster implementation
Data acquisition architecture
Graphics Processing architecture
23 24 25
Block diagram of MVC architecture
Flow chart for cluster implementation using MVC
architecture 29 31
6.1 6.2 6.3 6.4 6.5
Instrument cluster under normal condition
Dynamic cluster implementation
Indicator 34 34 36 38 38
Flow chart for cluster implementation
Non linear speedometer 45
CHAPTER 1: INTRODUCTION
The car multimedia systems primarily contain infota
inment, display, connectivity and
HMI solutions. Instrument clusters are the part of car multimedia systems, which
forms the display center for all the ECUs and other sensors inside the car. A driver or
a passenger knows any warning or any information or changes that happens inside the
car only through these instrument clusters.
Instrument Clusters are the graphical display units where the driver or a passenger can
gain the entire information of what happens inside a car. The primary focus of these
clusters is timely display of the data and warning. Thus, it helps to reducedriver
distraction and increase safety. In addition, these also provide interfaces through
buttons by which a user interacts with the car. Hen ce, the cluster serves as the human
machine interface (HMI). Some use cases of the clus terinclude:when a driver
accelerates his car, he should be aware of the spee d to which he accelerates. This
speed is displayed using a speedometer dial on the instrument cluster .Similarly, when
there is a failure in any part of the car, for e.g. Brakes, the driver learns this through
the brake failure telltale warning on the instrumen t cluster.
Traditional instrument clusters, contain precision mechanical devices on the cluster
and can display only limited information. They do n ot offer flexibility and
adaptability to display any more information. Later these precision mechanical
devices were replaced with electronics devices with the advent of microcontroller
As the technologyfurther advances, the complexity i n implementing the instrument
clusters increases. The latest instrument clusters includes the navigation system where
the map or the route from the start to destination is displayed on the cluster. Another
feature includes, establishing a wireless communica tion through a Bluetooth module
with the smart phones to access the media systems, call and phone book. In addition
,with the advent of advanced driver assistant syste ms (ADAS) ,the complexity of
designing the instrument cluster further increases. Some advanced driver assistant
1. Adaptive cruise control
– System implemented to adaptively adjust the vehicle
automatically to maintain a safe distance from the vehicle ahead.
2. Automatic braking
– System implemented to avoid high-speed collision th
3. Automatic Parking
– Autonomous system that automatically moves the car
into the parking
spot and parks it without the intervention of the d river.
4. Collision Avoidance Systems
– System to increase safety by avoiding collision wit
h multiple sensors.
5. Driver Drowsiness detection
– System implemented to detect the drowsiness state o
f driver and decide
if the driver is safe enough to drive.
6. GPS Navigation
– System to locate and guide the driver with the rout
e to destination.
7. Hill Descent Control
– System to control breaking when moving up and down
8. Intelligent Speed Adaption
– System implemented to ensure the speed of the vehic
le does not
exceed the safe speed limit.
9. Night Vision System
– Safety system to help driver to drive when dark.
The output of all these ADAS systems is either a wa rning or a graphics that need to be
displayed on the cluster. The advent of such system s not only increases the inputs to
the clusters but also the complexity of displaying them dynamically increases. For e.g.
the driver might need to play music, but at the sam e time it is required that the
speedometer dial and other telltales like fuel warn ing, brake warning are still on
display. Hence, with the advancement of technologie s and increase in safety systems
the complexity and challenge of graphically display ing the information increases.
With these systems being implemented in the automot ive, the warnings and inputs to
the instrument cluster increases. Also, the challen ge of prioritizing the inputs in a way
to aid safe driving increases. The success of imple mentation of these driver assistant
systems lies in the proper and timely display to th e driver.
In addition to the complexity of increasing data to be displayed, the instrument cluster
has to be designed in a way to reduce the distracti on of the driver and according to
driver’s comfort. Hence, a system needs to be desig ned that displays contents flexibly
adjusted and display only the information that the driver requires in the situation
concerned.Also, the cluster needs to be designed to meet the different requirements of
This project focuses on the design of a digital and freely programmable
instrumentation as a solution for a flexible, adjus table and dynamic display. A freely
programmable cluster allows to use the same archite cture for different requirements
and hardware. With these freely programmable cluste rs, a basic design cluster can be
modified to implement different variants of the clu ster. Hence, the time required to
design the cluster reduces considerably.
The fore coming chapters discuss the architecture o f the instrument clusters and
instrument cluster designed and implemented in this project.
CHAPTER 2: ARCHITECTURE
The general block diagram of an instrument cluster
is as shown in figure 2.1:
Fig 2.1 Block diagram of an instrument cluster
As seen in the block diagram, the functions of the instrument cluster are controlled by
microcontroller. The inputs to the instrument clust er are acquired from the different
ECUs present in different parts of the car. These inputs are acquired by the
microcontroller through a CAN bus interface and is encapsulated and graphically
rendered to the display unit of the instrument clus ter.
ECU stands for Electronic Control Unit. As its name suggests , it is the main
control unit of an automobile. It receives informat ion from sensors, makes
calculations and decisions based on the information received and operates the actuator
based on the calculations. It is thus referred to a s the brain of the system. The general
diagram of the ECU is as shown in figure 2.2.
Fig 2.2 Block diagram of ECU
As seen in the diagram above the input to an ECU is a sensor and output of the ECU
is an actuator.
The two primary roles of an ECU can thus be summari zes as,
i. Decision making – which depends on the accuracy of the information received
and the level of sophistication of the program.
ii. Control – Controlling the actuator (output of the s ystem) based on the decision
The blocks present inside an ECU is as shown in fig ure 2.3.
Fig 2.3 Blocks inside an ECU
It can be seen from the above diagram that the prim ary unit of the electronic control
unit is a microprocessor. The inputs acquires throu gh sensors may be either an analog
signal or a digital signal. Since the microprocesso rs can process only digital signals,
the analog signal is converted to a digital signal using an analog-to-digital converter
and then sent to the microprocessor.
The digital signals are directly sent to the microp rocessor. The microprocessor is the
primary unit inside the ECU which is responsible fo r decision making and generating
the output signals which controls the actuator. The microprocessor makes calculations
and decisions based on the instruction fetched from its program memory. Hence the
output of the ECU depends on how well it is program med. The microprocessor
operates only with weak signals. Hence the output s tage of the ECU consists of
amplifiers to amplify the output signal strong enou gh to operate the actuators.
Different systems inside a car have different ECUs for various purposes. A braking
system has an ECU to control how much brake pressur e should be applied on the
tyres based on the input from the wheel speed senso r. An adaptive cruise control
system has an ECU to adaptively adjust the speed of the vehicle to maintain a safe
distance with the forward vehicle based on inputs f rom lidar or radar sensors.
Thus, there are many ECUs that control different sy stems across the car. The outputs
of all the ECUs should not only drive the actuator but should be conveyed to the
driver to check for any warnings or to check if it is the expected output. For e.g. when
the driver accelerates, it is not enough if the ECU produces output such that increases
the speed but it is also necessary that it is conve yed to the driver. This area where the
information and warnings are displayed is called an instrument cluster. All the ECUs
form a network where the outputs are send. From th is common network the cluster’s
microcontroller acquires the output signals of diff erent ECUs and displays to the
In computer terms, it is known that a BUS is basica lly a communication system that
establishes communication between different nodes a nd components in a system. In
the automotive domain too, these buses are used to establish communication between
different components inside a car. Earlier, dedicat ed wires were used as buses to
connect the different components of a car. Thus a p oint to point communication was
As the technology advances, many systems have been introduced in cars to aid the
safety and comfort of the user. With increase in su ch systems, the number of ECUs
increases. This not only increases the complexity o f the data to be displayed but also
the number of wires used to connect the all these E CUs to the clusters. This
complexity of hardware connection through dedicated links has to be reduced. Thus,
there is a need for a shared communication medium. Hence, communication networks
are established to replace the traditional point to point communication by
communication multiplexed over a shred medium. This reduces the overall wire
There are basically four different car domains name ly
i. Power train
– controls engine transmissions
– Controls the safety systems.
iii. Chassis control
– Controls suspension, steering and braking systems.
iv. Telematics and HMI
– Telematics include the wireless communications like buetooth, GPS, radio and
other multimedia networks – HMI is the instrument cluster.
Each domain interacts with each other and among the mselves. Each domain have
their own data different from the other domain and thus require different speed and
Different in vehicle networks were established dif ferentiated by the speed and
bandwidth. The four in vehicle networks commonly us ed today are:
Inside the instrument cluster the CAN network is us ed.
CAN is Controller Area Network. It is a serial bus system. It is capable of connecting
multiple ECUs (microcontrollers) with one pair of w ire. The difference between
systems with CAN and without CAN is as shown in fig ure 2.4.
Fig 2.4 Systems with and without CAN
CAN was first introduced by the engineers at Robert BOSCH gmbh in Germany. It
proved to be a high speed, high integrity real tim e communication.
I. About the network:
i. It is a two-wire bidirectional serial bus communica tion method.
ii. It provides a data transfer rate up to 1 MB/s.
II. Main Features of CAN
i. It allows 0-8 bytes of user data per message.
ii. Puts multiple transmit or receive message boxes at each node and assigns each
iii. It causes receiving nodes to filter message based o n their assigned identifiers.
This feature thus allows CAN to permit message prio ritization and arbitration.
iv. It eliminates addressed of transmitting and receivi ng nodes in data messages.
This saves bandwidth and thus, allows simultaneous transmission of node-to-node and
v. It automatically retransfers message if corruption occurs.
vi. It provides error detection, signaling and fault co nfinement measures to ensure
highly reliable network operation.
CAN is a closed network. It does not require any us er interface. There is also no need
for security, sessions or logins. Hence the CAN can be implemented using the OSI
model architecture with only the physical, data lin k and application layers. The
architecture of can is as shown in figure 2.5.
Figs 2.5 CAN Architecture
i. Physical layer:
It contains the physical medium. That is, two wires terminated at both ends by a
resistor. Since only two wires are used, it reduces weight, cost and increases
CAN is a message oriented transmission protocol. Ea ch node in the Can bus has
receiver and a transmitter. The sender sends the in formation to all the nodes in CAN.
All the nodes receive and read the message and then decide if that message is required
by them. All nodes verify if the reception was erro r free by acknowledging the
ii. Data link layer:
This layer is responsible for the transfer of data between the nodes connected to the
CAN network. Each message has an ID, data and overh ead. The maximum data that
can be transmitted is of eight bytes.
The message format of the message transmitted in th e CAN bus is as shown in figure
Fig 2.6 Message Format
The three main fields in the message include:
iii. Error check
It is essential to consider the situation when mult iple nodes to communicate at the
same time. To avoid the confusion, the concept of b us arbitration is introduced.
According to the bus arbitration, only one transmit ter is allowed to transmit at a time.
Other nodes waits for the bus to become idle. Which transmitter gets the chance to
transmit is determined by the message ID. The node with lower value is more
important and wins transmission.
The CAN bus thus allows the communication of differ ent ECUs. Different users
transmit different data on the CAN bus. The microco ntroller in the instrument cluster
acquires the information from the CAN bus. More imp ortant messages like the brake
warning signals are transmitted with lower message ID in the CAN bus to win the
transmission over the other messages from other ECU s.
The microcontrollers are used for two primary reaso ns:
i. Data acquisition
ii. Graphics rendering
Graphics rendering is a time consuming and a comple x mathematical process. In
order to reduce the load on a single processor, two chipsets are used for the two
purposes. One chipset acquires the signals from the various ECUs through the can bus
interface and the second processor is basically a g raphical processing unit which is
solely responsible for graphics rendering and displ ay.
The details about the architecture of the two chips are discussed in the fore coming
The graphical rendered information is conveyed to t he driver using the display on the
instrument panel. The type of the display and its s ize varies for different variants and
CHAPTER 3: AUTOSAR
As discussed before, the complexity of the instrument cluster des
ign increases with
increase in the data to be displayed. The need for a display t hat is more flexible to
display dynamically is constantly increasing. The introduction of se veral safety and
comfort systems has increased the number of ECUs and their inter action. In addition
to the complexity in design, the manufacturers expect more innovati ve solutions in a
short period to cope with the competitors in the market. Thus, the cl uster has to be
designed in a way easy to modify, upgrade and update irrespective of i ts hardware
implementation. When such a cluster is designed, the existing cl usters can be
modified and updated to provide innovative solutions. Thus, the time take to design a
cluster is considerably reduced.
In addition, a single authority does not implement vehicle system s for a car. For e.g.
the clusters may be implemented by a different company. On the ot her hand, the air
bag systems may be implanted by another company. Even if the same automotive
company manufactures, different teams in that industry may be r esponsible for
individual systems. Hence, the way in which each system is i mplemented is inter
dependent since finally, ECUs interact to implement various f unctionalities across the
Hence, there is a need to standardize the implementations of th e software and
hardware modules inside the car. Such a standardized architecture is Automotive
Open System Architecture (AUTOSAR).
The motivation for such a standardization are as follows:
i. To manage the complex E/E complexity
ii. Flexibility to product medication, upgrade and update.
iii. Improve the quality and reliability of E/E systems.
The primary goals of AUTOSAR are as follows:
i. Fulfillment of future vehicle requirements, software updates, upg rades, and
ii. Increased stability and flexibility to integrate and transf er functions.
iii. Cost optimization of scalable systems
iv. Improved containment of products and process complexity and risk.
3.3 TECHNICAL GOALS:
The technical goals of AUTOSAR include the following.
This enables the ability to modify the automotive elements accor ding to the individual
requirements of the ECUs.
This indicates the ability of the automotive element to adapt to di fferent platform
variants. This prohibits automotive elements with same functi onality.
This optimizes the use of resources.
This improves the product quality and reliability.
The main principle of the AUTOSAR is “cooperate on standard, com pete on
The main objectives of AUTOSAR include:
i. Redundancy activation
ii. Consideration of availability and safety requirements.
iii. Scalability to different vehicle and platform variants.
iv. Implementation and standardization of basic functions as an industrywide
“standard core” solution
v. Transferability of functions from one ECU to another within the ne twork of
vi. Integration of functional modules from multiple suppliers
vii. Maintainability throughout the whole product life cycle
viii. Increased use of commercial-off-the-shelf (COTS) hardware
ix. Software updates and upgrades over vehicle lifetime
Hence, AUTOSAR makes it possible to control the complexity of the electrical and
electronic components, together with an increase in quality and profi tability. The
future of automotive engineering is in these modular and scalable AU TOSAR
The virtual functional bus is the abstraction of the AUTOSAR Software Components
interconnections of the entire vehicle. The communication between different software
components and between software components and its environment (e.g. hardware
driver, OS, services, etc.) can be specified independently of any underlying hardware.
The functionality of the VFB is provided by well-defined communic ation patterns.
The layered architecture of AUTOSAR is as shown in figure 3.1 and 3.2.
Fig.3.1 Layered architecture of AUTOSAR
Fig 3.2 Detailed layered architecture of AUTOSAR.
As seen in the above figure, the fundamental goal of AUTOSAR i s the separation of
the application and hardware. Any system inside the car is im plemented based on this
architecture. The three main parts of this architecture is :
i. Basic software
ii. Run Time Environment (RTE).
iii. Application Layer.
3.5.1. BASIC SOFTWARE
The basic software layer can be further divide d into different layers as:
i. Microcontroller abstraction layer
This layer provide the access to the hardware. Thi s is the lowest layer. It
contains the low-level drivers with direct access to microcontr ollerperipherals below
it. It is responsible for proving abstractions to the microcontr oller . These devices
a. microcontroller drivers,
b. memory drivers, communication drivers and
c. Input/output (I/O) drivers.
ECU abstraction layer:
This layer is responsible for providing abstraction to the ECU har dware layout from
the layers above it. This is above the microcontroller abstrac tion layer, which provides
access to the hardware components outside the microcontroller on the ECU.
Components included here include:
a. Watchdog interface
b. CAN interface etc.
Thus, it contains drivers for external devices. It provides an
interface for access to peripherals and external devices.
iii. Service layer:
This is the highest layer of the basic software This layer is above the ECU abstraction
layer and serves to provide the basic software functionali ty to the application.
Components included in this layer include:
c. NM etc.
The service layer offers the following fu nctionalities:
1. Operating system functionality
2. Vehicle network communication and management services
3. Memory services (NVRAM management)
4. Diagnostic services (including UDS communication, error memory a nd fault
5. ECU state management
3.5.2 AUTOSAR OS
The AUTOSAR OS accesses the hardware in order to manage the timer
for time sliced scheduling.
3.5.3 COMPLEX DEVICE DRIVER
Like the OS, Complex device driver is also allowed to dir ectly access the hardware.
The purpose of the complex device drivers is to extend the standa rdized part of the
architecture with new device drivers, which have not yet bee n standardized.
3.5.4 RUN TIME ENVIRONMENT
This layer separates the basic soft ware from the application layer. The
primary task is to make the AUTOSAR componens independent from ma pping to a
single ECU. This acts as a center for inter and intra ECU c ommunication. This enable
easy integration of customer specific software functional m odules. Thus, this layer
strictly separates basic software and application layer. I t totally shields the application
layer from the peculiarities of the basic software and all ows success in a clearly
defined way.Thus, this layer provides communication services t o applications.From
the viewpoint of the AUTOSAR, the RTE implements the VFB funct ionality on a
3.5.5 APPLICATION LAYER
This contains the actual system like the Antilock brak ing system(ABS),
Electronic stability system (ESP) , instrument cluster et c.
From the brief description about the architecture of AUTOSAR, the key features of
AUTOSAR can be concluded as:
i. Modularity and Configurability
This implies the Definition of a modular architecture for automotive electronic control units.
Resource optimized configuration of the SW infrastructure of each E CU
depending on the function deployment. Scalability of the E/E-system across the entire range of vehicle product lines
ii. Standardized features
Standardization of different APIs to separate the AUTOSAR S W layers
iii. Run time environment.
AUTOSAR runtime environment to provide inter- and intra-ECU communi cation
across all nodes of a vehicle network. Thus, it enables the ea sy integration of
customer specific functional SW-modules
Hence, every system implemented must comply with the AUTOSAR standards. This
applies to the instrument cluster too. The following chapter di scusses how the general
block diagram of the instrument cluster discussed in the previous ch apter is
implemented using the AUTOSAR architecture.
DUAL CORE CLUSTER ARCHITECTURE
CHAPTER 4: DUAL CORE CLUSTER ARCHITECTURE
As discussed in previous chapter, the instrument cl
uster architecture is also
implemented using the AUTOSAR standards. The cluste r has two chipsets. It is
implemented using the architecture as described in figure 4.1.
Fig 4.1 Dual core cluster architecture
As described in the AUTOSAR, the application layer is separated from the basic
software layer using the RTE layer. Different appli cations connected to different
ECUs or to the same ECUs communicate using this RTE layer.
4.1 DATA ACQUISITION:
The first chipset acquires the signals from differe nt application inside the car. These
signals are acquired via the CAN bus. The acquired signals are processed to a
primitive data type and are transmitted to the grap hical processing unit using an
The architecture of the data acquisition part is as shown in figure 4.2
Fig 4.2 Data acquisition architecture
As seen in the block diagram, the different systems ‘ ECUs like the ABS ECU, fuel
tank ECU etc. for the application layer of the arch itecture. The signals from the
different ECUs are sent to the Run Time Environment (RTE), which converts these
signals to CAN signals. It is from here that the CA N driver receives the signal and
transmits it to the interface separating this proce ss from the graphical processor.
This interface not only transfers the information b etween these two processors but
also acts as a filter. For e.g. if the first chip c ontinuously process and send the same
speed value to the graphical processor, it renders and displays the same graphical
The graphics processor does the complex calculation s and rendering to display the
same value. This can be avoided by sending the spee d value only when it changes.
This filtering is taken care by the interface that separates the two chip. The graphics
processor acquires the input.
4.3 GRAPHICAL PROCESSING:
The input value is a primitive data ty pe and has to be encapsulated in a form
visually understood by the processor. The architect ure for the graphical rendering
processor is as shown in figure 4.3.
Fig 4.3 Graphics processing architecture
As seen in the architecture diagram, the applicatio n layer contains the display, in
which the information is conveyed to the driver.
Before going into the details of the architecture, it is necessary to know what is
graphics rendering. In simple words, rendering is t he process of adding features like
colour, shades etc. to create a photo realistic ima ge.
The different components of the architecture includ e:
1. Graphical Processing Unit
The microcontroller seen in the figure is a graphic al processing unit. It is basically an
electronic chip. This circuit manipulates the memor y to build images that are to be
displayed. It is a chip, whose sole purpose is to r ender images by performing rapid
mathematical calculations.These chips were introduc ed to reduce the load on the
already loaded CPUs, in this case , the data acquis ition microcontroller.
2. Graphics Engine and Graphics library
This software does the rendering of th e images to the application layer, here the
display. The graphics engine uses the interfaces de fined in the graphics library to
render the image. These graphics libraries are the application-programming interface
(API).It is a software library that interacts with the GPU for accessing its features.
Usually, the graphics library is defined in such a way that it is hardware independent
and is compatable with different GPUs. The graphi cs engine implements the
interfaces defined in these software libraries acco rding to the application it has to
render. These components fall under the basic software part in the AUTOSAR
3. Application Layer
The application layer is the display used. The size and other specifications
of the display is as specified by the customer.
Here also the communication is established by the C AN network.
Inside this graphics system, how the data is receiv ed, rendered and displayed
can be implemented using Model-View-Controller arch itecture. The details
about why the architecture is used and how it is im plemented are discussed in
the next chapter.
CHAPTER 5: MVC ARCHITECTURE
As discussed in the previous chapter, the graphics
processing system is the Human
Machine Interface inside the car. The primary role of the graphical processing system
can be divided into three:
i. To receive and store data from the interface separa ting from the data
ii. To activate and deactivate the components in the cl uster as and when
required, as well as on startup and shutdown.
iii. To graphically display on the panel to the user.
Hence the HMI can be implemented by dividing it int o three distinct and discrete
components. Each such component is responsible only for one of the primary roles.
By doing so, each component is only responsible for that single function. Hence, such
a separation increases modularity.
Thus the complexity of HMI implementation reduces considerably, making the
cluster more dynamic and adaptable to use.
Such a HMI implementation can be achieved by the Mo del-View-Controller
architecture. The general block diagram of the MVC architecture is shown in figure
Fig 5.1 Block Diagram of MVC architecture
As seen in the block diagram, the three components are:
This component handles data. Its primary role is to receive data
from the interface separating the two chips in the cluster and to
transmit this data when other components in the arc hitecture
needs. Thus it is this component that decides what data to be
displayed on the cluster. The entire cluster depend s on this
component for data.
Apart from transmitting data to view or the control ler, it also
notifies the architecture when there is change in d ata.
This component is responsible for the a ctivation and
deactivation of the different elements in the clust er. That is, it is
this component that decided when to display the ele ments.
It works as an event triggered mechanism. That is, when a
particular event occurs, an element in the cluster is accordingly
activated and deactivated.
Thus , the controller is implemented as a state mac hine. Just like a
state machine, which changes its state on the occur rence of an
event, the controller part in the instrument cluste r changes the
state from activation to deactivation or vice versa based on the
occurrence of an event.
This component forms the display part of th e cluster. This
part decides how a data should be displayed on the cluster.
It is in this component that the entire HMI applic ation is
designed. That is, it is here that the position, si ze and various
other design factors of each element in the cluste r is decided.
It is here that the graphics rendering in done. Thu s, this forms the
final component of the instrument cluster.
The three components perform three distinct roles, but are dependent on each other
primarily for the input data. For instance, the vie w component interacts with the
model to receive any input data to be displayed lik e the speed data. Similarly, the
view interacts with controller to activate or deact ivate any element on the cluster like
the warning symbols. Thus to implement a cluster th e three components continuously
interact with each other.
This interaction happens asynchronously. That is, i n a asynchronous communication
the data or a message is continuously posted by the sender without waiting for an
acknowledgement from the receiver. That is the tran smission and reception of data is
Similarly, here in the cluster, the model send the data that it receives the data from the
interface and does not expect an acknowledgement fr om the receiver.
Thus, to implement an asynchronous communication, t he interaction between the
three components is established using messages.
That is, the data received by the model component i s encapsulated as messages inside
the model component.
A message queue is created to hold the messages pos ted by the model component
until it is consumed by either the view or controll er or both the components. In this
way a communication is established between the comp onents of the architecture.
Thus a MVC architecture is a software architecture pattern, which is commonly used
in user interface application , here, HMI. This arc hitecture promotes modularity ,
resuse and collaboration by logically sepearating t he application into three distinct
The general flow of the data can be represented by the following diagram:
Fig 5.2 Flow chart of the cluster implementation us ing MVC architecture
CHAPTER 6: IMPLEMENTATION
6.1 STEPS INVOLVED IN DESIGNING AN INSTRUMENT
6.1.1 REQUIREMENT ANALYSIS
The motive of this project implementation is to
design and implement
a cluster as per the requirements given by the cust omers (OEMs). Hence, the first step
in designing a cluster is requirement gathering.
In this step, the cluster design is gathered from t he OEMs. Different OEMs have their
own design specified. The designs vary in wide vari eties especially in the position of
the components (Speedometer, indicator, warnings et c.) on the instrument cluster.
Also, the designs take into considerations the driv er comfort and safety and thus,
many designs with different variants ranging from l ow to high is proposed.
As discussed earlier, the technology advancements e xpect the traditional mechanical
and electronic clusters with fixed displays to be r eplaced by clusters more dynamic
and flexible. This is because the traditional clust ers, involve more hardware like the
gauges, LEDs etc., which are static in their positi on. This restricts the amount of
information that can be displayed on the cluster.
Also, when more systems are introduced, it is neces sary that the cluster just displays
what the driver needs at the current situation, rat her than displaying all the
Hence, this project concentrates on a fully digital and freely programmable cluster
design. The need for such a cluster is illustrated in figure 6.1 and 6.2.
Fig 6.1. Instrument cluster under normal scenario.
Fig 6.2 Dynamic instrument cluster implementation.
As seen in the above figures, An element occupying larger size has to be displayed .
But, at the same time speed value has to be display ed. Hence, both the dials are
pushed to the side in a way visible to the driver. This can be achieved only by a
dynamic instrument cluster.
When the cluster is fully digital, it becomes easie r for dynamic display. A freely
programmable cluster makes it easier to modify and upgrade an already designed
cluster to different variants.
The OEMs gives these inputs as photo. With that pho to as reference, the exact cluster
is designed, with exactly all the components in the ir exact position specified.
6.1.2 SYSTEM ANALYSIS
After gathering the photo of th e cluster design, the design is completely
analysed. Each component functionality is studied. In this the project, the main aim is
implementing speedometer, tachometer, indicator and fuel bar. Thus, functionality of
each is studied to implement the same in the cluste r. Here,
i. Speedometer – This is used to indicate the current speed of the vehicle.
ii. Tachometer –This is used to indicate the Revolution s per Minute (RPM) of the
iii. Indicators – These are used to indicate the directi on of turn of the car. Also,
they can be used as warning to indicate that the ca r is moving slow, and in some cases
they can be used when it is too foggy and misty. In these cases, both the indicators are
iv. Fuel bar – This is used to indicate the amount of f uel in the fuel tank.
The functionality study is done to understand how the element has to be implemented
on the display. A thorough system study and thus th e functionality study is needed for
better implementation of the design.
In addition, the resources required to design the s cene is analysed. The main aim is to
design an innovative cluster with minimum resources .
6.1.3 MODULE DESIGN
After analyzing the photo of the cluste r, it is exported to the scene-designing
tool. Each component of the cluster such as the spe edometer, tachometer etc. are
designed as separate scenes in this scene-designing tool.
In the scene-designing tool, the photo of the requi red cluster is imported. In this
process, every component is imported with exactly t he same position and size as
required by the customer.
Then, each component of the cluster is exported ins ide the scene-designing tool as
separate scenes. By doing so, the each component is separated, retaining its position
and size. Now, each scene is designed separately. A fter all the scenes are designed,
assets are generated which integrates the separatel y designed scene on a common
i. Speedometer Scene
In the given graphics, the speedometer designed is as shown in figure 6.3.
The speedometer forms the left dial of the given cl uster graphics.
As seen in figure, the speedometer represents speed using both analog dials and
digital speed. In contrast to the mechanical analog ue gauges used to represent the
analogue speed, the entire graphics is a digital di splay. Hence, each component in the
speedometer which includes,
II. Analogue speed
IV. Digital speed
Each of the above, are imported as separate compone nts in the scene. These
components are either bitmap images or text and are referred to as a node. In this
scene except the digital speed value, all others ar e bitmap nodes. In this scene-
designing tool, each bitmaps placed in the exact po sitions as required. The bitmap is
bounded by a rectangle with a pivot point. This poi nt is the point of reference for any
transformation like scaling or rotating done to the bitmap. For e.g. the needle’s pivot
point has to positioned such that it rotates accura tely to indicate the analogue speed.
Note that in figure 6.3, the dial is closer than an alogue speed values. Similarly each
bitmap node or text node in the scene are arranged in different layers. Some may be
close and some may be farther from the screen. The parameter that differentiates this
layers is called as the depth value. Comparing with the photo given by the customer,
the depth value is calculated and assigned accordin gly to each node.
Thus, each node in this scene is positioned and arr anged. The static scene is thus
After designing the static design, the functionalit y has to added or in other words,
dynamicity has to be added to the scene. The entity that adds dynamicity is called the
widget. The scene-designing tool has offers differe nt widgets to implement different
a. Transformation – for rotating and scaling
b. Tube – for rotating
c. Text Effect- to display a text
d. Telltale – to indicate a warning
In the tool, each node in the scene is associated w ith the respective widget to
implement the scene. Here, for instance the needle is associated with a tube widget.
Similar to speedometer , other scenes are implement ed.
ii. Tachometer scene
The design of tachometer is similar to the speedome ter as it has the same components
as the speedometer. The tachometer in the given gra phics is the right dial. The
tachometer designed is as shown in figure 6.4.
Fig 6.4 Tachometer
The tachometer is similar to the speedometer and it also has needle, dial, analogue
RPM dial etc. As discussed in the speedometer scene , the tachometer is first designed
statically and then widgets are added to the nodes to add dynamicity.
iii. Indicator Scene:
The indicators implemented in the cluster are as sh own in figure 6.5.
Fig 6.5 Indicators
In contrast to the other two scene, here there is n o rotation involved. The indicators
have to blink according to the input key. Hence, he re telltale widgts are added to the
two bitmap nodes i.e., the left and right arrow.
iv. Fuel Bar:
The fuel bar implemented in the cluster graphics is as shown in figure 6.6.
Fig 6.6 Fuel Bar
Here, the fuel level has to increase or decrease ac cording to the level of fuel in the
tank. Since it is a linear movement, a bar graph wi dget is used.
Hence, in the scene-designing tool, each scene is p ositioned statically and the widgets
are assigned to the respective nodes. It is importa nt to note that, till this point, the
nodes are just associated to the widgets. For insta nce, the needle of the dials is
assigned to the tube widget because its function is to rotate. But, how much the needle
has to rotate, when it has to rotate is not yet con figured. That is, the cluster has to
become functional. The cluster has to take inputs a nd react accordingly. This is
achieved through codes.
After the cluster is designed using the scene-designing tool, its functionality
has to be implemented. After successful implementat ion, it has to be verified in the
PC. On successful verification, it is flashed on to the target and tested in the target,
after which it is delivered to the customer.
The implementation of cluster is through coding. As discussed in the previous
chapter, the clusters are implemented using the MVC architecture. The MVC
architecture is achieved by implementing using a fr amework. The framework has
interfaces and classes which can be derived and mod ified to implement the desired
As discussed before, the interaction between the th ree components is asynchronous
and hence through messages. Hence, the data receive d through the interface is
encapsulated to a message. How the module designed in the scene-designing tool is
implemented is discussed below.
First, each scene’s path is mapped to an ID, to int erface the scene designed in the tool
to the code. After mapping all the scenes, the view part of the entire scene is designed.
It is already known that the view part is responsib le for the graphical display. That is,
it is this component that decides how that data has to be displayed.
Inside every view part, there is a controller calle d view controllers. These are the main
part of the view component whose primary role is to initiate the widgets. These view
controllers are nothing but simple cpp codes, writt en to receive the data from the
model and initiates the widgets to display the valu e accordingly. That is, when a tube
widget has to rotate and the value to which it has to rotate is given to the widgets
through the view controllers.
In the cluster design for instance, speed view cont rollers are written to render the
speedometer scene. Inside this view controller, fun ctions are defined to receive the
speed value from the model. The value is then initi alized to the pointer to the tube
widget. Then the widget rotates to indicate the val ue received.
Thus to summarize:
A cluster is designed using a scene-designing tool after the requirement and system
analysis is done. The cluster designed is non funct ionality. The functionality is added
by writing the view controller codes. It is importa nt to understand at this point that,
controller activates or deactivates the scene. And, only when the view controllers are
created the scene is rendered and can receive messa ges.
The cluster is thus successfully implemented using the MVC architecture.
6.1.5 TESTING AND FLASHING
The designed cluster has to be tested to verify its functionality. The
instrument cluster designed in the PC is not in an automotive environment. There is
no ECUs, CAN networks and any system. But the desig ned scene has to be tested for
its optimized implementation. Testing the design in PC reduces the cost of testing
directly in the car. So, it is necessary to virtual ly create a system or a processor that
posts its input to the model component in the archi tecture.
To mock such a system, the inputs or rather the key s from the keyboard are used as
acquired input signals in the original implementati on. For instance, the key ‘A’ from
the keyboard can be treated as the input speed valu e and so on. Codes are written to
receive this value as the acquired speed value and are sent to the model component.
The model component then encapsulates this value wh ich is of primitive data type and
posts it to the message queue, from which the view and controller part receive the data
if they need. Thus the functionality of the designe d cluster can be tested using the PC.
Then asset or the binary files are generated and fl ashed to the target hardware and
further tested on the target hardware.
The target hardware is just the cluster hardware al one. That is, it is not connected to
car. Thus a simulator is used to generate the neces sary CAN signals and verify the
functionality of the cluster.
The implementation steps involved can be represente d in a flow chart as shown in
Fig 6.7 Flow chart for the cluster implementation
The next chapter briefly describes the design chall enges faced during the project
CHAPTER 7: DESIGN CHALLENGES
The previous chapter discussed how the cluster was
designed and implemented in the
project. The designing and implementation of the cl uster was summarized in the
It can be inferred that designing the cluster is a complex task. But, the introduction of
the freely programmable and digital cluster enhance s the modularity of the cluster
design. It makes it easier for upgrade and reuse.
There is lot of design challenges involved with the project implementation:
1. The first challenge is the static design of the clu ster. This project primarily
focuses on the speedometer and tachometer dials. Ea ch dial have a needle
which rotates to denote the analogue speed. Thus, i t can be understood that the
perfect rotation is needed to indicate the perfect speed value. This entire
depends on the position of the needle and the posit ion of point around which it
rotates. The point around which the needle rotates is called the pivot point.
Several mathematical calculations were done to loca te this pivot point of the
2. The second challenge is the depth value. As discuss ed in the previous chapter,
the depth value is used to differentiate the differ ent components in scene from
farthest to nearest. Assigning the depth value was a great challenge.
3. Designing a scene in such way that it does not over lap with other scenes on
the cluster is a tedious task.
4. While associating the different components of the s cene to a widget, the
correct widget with which the functionality can be achieved with minimum
codes has to be identified. This is important becau se there may be more that
one widget with the same functionality. But, each m ay differ in the complexity
of implementation. For e.g. both tube widget and tr ansformation widget can
achieve rotation. But the transformation widget req uires us to manually map
each speed value to an angle. On the other hand, tu be widget does the mapping
manually which saces some lines of code and calcula tion.
Hence, it is necessary to identify the appropriate widgets.
5. The speedometer designed in the project is shown in figure 7.1.
Fig 7.1 Non Linear Speedometer
As seen in the figure, the analogue speed values a re non line. That is it has
different scales before and after 200. Hence a form ula was devised in such a
way that the correct value is represented in spite of the non linearity.
The above stated challenges are during the design p hase. Interfacing the
design, with the codes, to implement the functional ity results in a lot of build
errors to be rectified. The different testing incl uding th PC simulation and the
target testing also results in errors and increases the challenge of implementing
Thus this chapter discussed briefly some of the des ign challenges faced during
CHAPTER 8: CONCLUSION
This project primarily focuses on implementation of
speedometer, tachometer ,
indicator and fuel bar scenes on the instrument clu ster. Each scene are separately
rendered, interfaced and implemented in the PC. On successful verification in the PC
these are then flashed to the target hardware.
As a solution to the traditional cluster with fixe d displays, mechanical and electronic
gauges, this project implement a fully digital clus ter. Thus, the cluster implemented
can display data dynamically.
The architecture of the instrument cluster follows the architecture specified by the
AUTOSAR components. The HMI part of the cluster is implemented using a MVC
architecture to increase the modularity and logical ly separate the three distinct roles of
Thus, the digital cluster containing the speedomete r, tachometer, indicator and fuel
bar was successfully implemented and verified in PC and the target hardware.
1. B. Balasubramanian, “Development of low-cost u niversal instrument
cluster,” 2015 IEEE International Transportation Electrificat ion Conference
(ITEC) , Chennai, 2015, pp. 1-7.
2. Osswald, Sebastian ; Sheth, Pratik ; Tscheligi , Manfred. (2013).
Hardware-in-the-Loop-Based Evaluation Platform for Automotive Instrument
Cluster Development (EPIC). EICS 2013 – Proceedings of the ACM SIGCHI
Symposium on Engineering Interactive Computing Syst ems.
3. H. Bo, D. Hui, W. Dafang and Z. Guifan, “Basic Concepts on AUTOSAR
Development,” 2010 International Conference on Intelligent Comput ation
Technology and Automation , Changsha, China, 2010, pp. 871-873.
4. Dey, T.: A Comparative Analysis on Modeling an d Implementing with
MVC Architecture. In: IJCA Proceedings on Internati onal Conference on Web
Services Computing (ICWSC), pp. 44–49. Published by Foundation of
Computer Science, New York (2011)
5. Bosch Automotive Handbook by Robert Bosch Gmbh.
6. Referred company website for some detail s specific to the company.