i dials in instrument clusters”. Submitted by CB.EN.U4ECE14239

i GRAPHICS RENDERING, INTERFACING AND IMPLEMENTATION OF DIALS IN INSRUMENT CLUSTER A PROJECT REPORT Submitted by CB.EN.U4ECE14239 NIVETHASHRI.S Under the guidance of Mr. GEETHANATHAN SUNDERESAN in partial fulfillment of the requirements for the award of the degree of BACHELOR OF TECHNOLOGY IN ELECTRONICS AND COMMUNICATION ENGINEERING AMRITA SCHOOL OF ENGINEERING COIMBATORE 641112 June 2018ii AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING, COIMBATORE, 641112 BONAFIDE CERTIFICATE This is to certify that the project report entitled ” Graphics rendering, interfacing and implementation of dials in instrument clusters”. Submitted by CB.EN.U4ECE14239 NIVETHASHRI.

S 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.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

P. Sudeesh Asst. Professor Architect Asst.

Professor RBEI Private Limited Chairman ECE Dr. M. Jayakumar The project was evaluated by us on: Internal Examiner External ExaminerINTERNSHIP COMPLETION CERTFICATE iiiiv ACKNOWLEDGEMENT 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 the successful completion of my project.

v ABSTRACT 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.vi TABLE OF CONTENTS CHAPTER NO TITLE PAGE NO ABSTRACT v LIST OF ABBREVIATIONS viii LIST OF FIGURES ix 1 INTRODUCTION 1 2 ARCHITECTURE 2.1 ECU 2.

2 BUS 2.2.1 CAN BUS 2.

3 MICROCONTROLLER 5 6 8 10 12 3 AUTOSAR 3.1 MOTIVATION 3.2 GOALS 3.3 TECHNICAL GOALS 3.4 OBJECTIVES 3.5 ARCITECTURE 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 20vii 4 DUAL CORE CLUSTER IMPLEMENTATION 4.1 DATA ACQUISITION 4.2 INTERFACE 4.3 GRAPHICAL PROCESSING 22 23 24 25 5 MVC ARCHITECTURE 27 6 IMPLEMENTATION 6.1 STEPS INVLOVLED IN DESIGNING AN INSTRUMENT CLUSTER 6.

1.1 REQUIREMENT ANALYSIS 6.1.2 SYSTEM ANALYSIS 6.1.

3 MODULE DESIGN 6.1.4 CODING 6.1.

5 TESTING AND FLASHING 32 33 33 35 35 39 41 7 DESIGN CHALLENGES 43 8 CONCLUSION 47 REFERENCES 48viii 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 9ix LIST OF FIGURES FIGURE NO TITLE PAGE NO 2.1 2.2 2.3 2.

4 2.5 2.6 Block diagram of an instrument cluster Block diagram of ECU Blocks inside an ECU System with and without CAN CAN architecture Message Format 6 7 7 10 11 12 3.1 3.

2 Layered architecture of AUTOSAR Detailed layered architecture of AUTOSAR 17 18 4.1 4.2 4.3 Dual core cluster implementation Data acquisition architecture Graphics Processing architecture 23 24 25 5.1 5.2 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 Speedometer Tachometer Indicator 34 34 36 38 38x 6.6 6.7 Fuel bar Flow chart for cluster implementation 39 42 7.1 Non linear speedometer 451 CHAPTER 1 INTRODUCTION2 CHAPTER 1: INTRODUCTION The car multimedia systems primarily contain infotainment, 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 technology. 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 systems include:3 1. Adaptive cruise control – System implemented to adaptively adjust the vehicle speed automatically to maintain a safe distance from the vehicle ahead.

2. Automatic braking – System implemented to avoid high-speed collision through sensor fusion. 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 with multiple sensors. 5. Driver Drowsiness detection – System implemented to detect the drowsiness state of driver and decide if the driver is safe enough to drive.

6. GPS Navigation – System to locate and guide the driver with the route to destination. 7. Hill Descent Control – System to control breaking when moving up and down the hill. 8. Intelligent Speed Adaption – System implemented to ensure the speed of the vehicle 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.4 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 different OEMs. 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.5 CHAPTER 2 ARCHITECTURE6 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.

2.1 ECU 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.

7 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 made. The blocks present inside an ECU is as shown in fig ure 2.3.

Fig 2.3 Blocks inside an ECU8 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 driver. 2.2 BUS 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 to9 connect the different components of a car. Thus a p oint to point communication was established.

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 harness. There are basically four different car domains name ly i. Power train – controls engine transmissions ii. Body – 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 bandwidth. Different in vehicle networks were established dif ferentiated by the speed and bandwidth.

The four in vehicle networks commonly us ed today are: i. CAN ii. LIN iii. MOST iv. FLEXRAY Inside the instrument cluster the CAN network is us ed.10 2.2.1 CAN 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 an identifier. 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 broadcast messages. 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.11 III. Architecture: 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 reliability.

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 reception. 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 2.6.12 Fig 2.6 Message Format The three main fields in the message include: i. Identifier ii. Data 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. 2.3 MICROCONTROLLER 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 two13 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 chapter. 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 different OEMs.14 CHAPTER 3 AUTOSAR15 CHAPTER 3: AUTOSAR As discussed before, the complexity of the instrument cluster design 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 car. 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). 3.1 MOTIVATION 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.

3.2 GOALS The primary goals of AUTOSAR are as follows: i. Fulfillment of future vehicle requirements, software updates, upg rades, and maintainability.16 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. i. Modularity This enables the ability to modify the automotive elements accor ding to the individual requirements of the ECUs. ii. Scalability This indicates the ability of the automotive element to adapt to di fferent platform variants.

This prohibits automotive elements with same functi onality. iii. Transferability This optimizes the use of resources. iv. Re-usability This improves the product quality and reliability. 3.

4 OBJECTIVES: The main principle of the AUTOSAR is “cooperate on standard, com pete on implementation”. 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 ECUs 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 lifetime17 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 software architectures. 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.

3.5 ARCHITECTURE: The layered architecture of AUTOSAR is as shown in figure 3.1 and 3.2. Fig.3.1 Layered architecture of AUTOSAR18 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 include: a.

microcontroller drivers, b. memory drivers, communication drivers and c. Input/output (I/O) drivers.19 ii. 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: a. NVRAM b. DEM 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 treatment), 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.

20 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 specific ECU. 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.21 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.22 CHAPTER 4 DUAL CORE CLUSTER ARCHITECTURE23 CHAPTER 4: DUAL CORE CLUSTER ARCHITECTURE As discussed in previous chapter, the instrument cluster 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 interface. The architecture of the data acquisition part is as shown in figure 4.224 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. 4.2 INTERFACE 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 value.

25 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.26 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 architecture. 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.27 CHAPTER 5 MVC ARCHITECTURE28 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 acquisition processor. 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 5.

1.29 Fig 5.1 Block Diagram of MVC architecture As seen in the block diagram, the three components are: i. Model 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.30 ii. Controller 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. iii. View 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 not synchronized.31 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 parts. 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 architecture32 CHAPTER 6 IMPLEMENTATION33 CHAPTER 6: IMPLEMENTATION 6.1 STEPS INVOLVED IN DESIGNING AN INSTRUMENT CLUSTER 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 information. 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.34 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.35 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 wheel. 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 turned on. 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,36 assets are generated which integrates the separatel y designed scene on a common display. i. Speedometer Scene In the given graphics, the speedometer designed is as shown in figure 6.3. Fig.6.3 Speedometer 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, I. Dial II. Analogue speed III. Needle IV. Digital speed V. Unit 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 this37 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 designed successfully. 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 functionalities like: 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.38 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.39 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. 6.1.4 CODING 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 functionality.40 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.41 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 figure 6.7:42 Fig 6.7 Flow chart for the cluster implementation The next chapter briefly describes the design chall enges faced during the project implementation.43 CHAPTER 7 DESIGN CHALLENGES44 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 previous chapter. 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 needle. 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 map45 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 a cluster. Thus this chapter discussed briefly some of the des ign challenges faced during implementation phase.46 CHAPTER 8 CONCLUSION47 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 the cluster. Thus, the digital cluster containing the speedomete r, tachometer, indicator and fuel bar was successfully implemented and verified in PC and the target hardware.48 REFERENCES49 REFERENCES 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. 10.1145/2480296.2480305. 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. doi: 10.1109/ICICTA.2010.571 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.

x

Hi!
I'm Casey!

Would you like to get a custom essay? How about receiving a customized one?

Check it out