04_Tesis

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE OCCIDENTE

Especialidad en Sistemas Embebidos

Reconocimiento de Validez Oficial de Estudios de nivel superior según Acuerdo Secretarial 15018, publicado en el Diario Oficial de la Federación el 29 de noviembre de 1976.

DEPARTAMENTO DE ELECTRÓNICA, SISTEMAS E INFORMÁTICA

Sistema embebido de Clúster AutomotrizBasado en la tarjeta S12HY64 Freescale

Documento de Trabajo Terminal


Presenta

Antonio Rafael Cabrera Ansaldo SE51806

Danilo González Cruz SE56304

Asesor: Héctor Antonio Rivas Silva

Guadalajara, Jalisco, Agosto 2014





Embedded Automotive Cluster ProjectBased on the S12HY64 Freescale board.

Final Project Document Report

Embedded systems specialization

Presents

Antonio Rafael Cabrera Ansaldo SE51806

Danilo González Cruz SE56304

Advisor: Héctor Antonio Rivas Silva

Guadalajara, Jalisco, August 2014

2


Especialidad en Sistemas Embebidos 003466



Sistema embebido de Clúster AutomotrizBasado en la tarjeta S12HY64 Freescale

Documento de Trabajo Terminal

Presenta

Antonio Rafael Cabrera AnsaldoCVU 510005, No Beca 358404

Danilo González Cruz

Asesor: Héctor Antonio Rivas Silva

Convocatoria de Becas Nacionales 2013 Primer Periodo 290747

Guadalajara, Jalisco, Agosto 2014

3

AgradecimientosQueremos agradecer a la institución por crear este programa que nos ha permitido desarrollar y enfocar nuestras habilidades hacia un campo que nos apasiona y tiene un gran camino por recorrer. A nuestros maestros, Héctor Rivas, Abraham Tezmol, Álvaro Oceguera, Alan Collins y Luis Garabito por brindarnos siempre sus conocimientos, tiempo y dedicación y hacer de estas clases algo especial. Al Dr. Raúl Campos por conducir la especialidad y siempre estar buscando mejorarla, incorporando temas y elementos para volverla más dinámica y funcional a los requerimientos de la industria. A nuestros compañeros por que fue un trabajo de equipo, el interactuar con ellos hizo más amena la experiencia, además de también aprender de ellos muchas cosas. A nuestros padres por apoyarnos en todo momento, tanto económica como moralmente, fue un año pesado y gracias a ellos se pudo solventar. Danilo agradece a Alejandra por ser esa persona especial en su vida y por todo lo que le ha dado.

Agradecemos de igual y especial manera al CONACYT por creer en este programa y dar un apoyo invaluable no solo a nosotros si no a futuras generaciones que se estarán formando en estas aulas.

AcknowledgementsWe'd like to thank the institution for creating this education program that has developed and focused our abilities towards a field that we enjoy and has a lot of potential. To our teachers, Héctor Rivas, Abraham Tezmol, Álvaro Oceguera, Alan Collins and Luis Garabito for giving us their knowledge, time and efforts to make something very special. To the Dr. Raul Campos for conducting the specialization program and always looking to improve it by the way of new subjects and elements that evolves into something more dynamical and productive, aimed for our development for the industry. To our classmates, because this was a shared effort, and interacting with them made a more enjoyable experience, beside their skills have remained in us, beside their friendships. To our parents for the eternal support, both monetary and spiritual, this was a tough year and thanks to them this could be resolved. Danilo deeply thanks Alejandra for being that special person in his life and for everything she gives to him.

We thank in a very special way the CONACYT for believing in this program and give their invaluable support not only to us but also to future generations that will be studying in these classrooms.

4

AbstractA cluster device that performs all the communications with CAN messages and it’s based on a scheduler operative system. The project was realized with the V-cycle software development mode and follows the steps of requirements, design, coding, compiling and testing. Software architecture was implemented to facilitate constant maintenance and evolution of the source code. This project is part of an extensive array of modules to develop an in-house vehicle powered by students.

5

ResumenEl proyecto que se realizó para la obtención del grado de la especialidad en sistemas

embebidos se trata del desarrollo de un “Clúster” o conocido mejor como el tablero de automóvil, el cual despliega una serie de mensajes informativos a los usuarios, tales como la velocidad, kilometraje, temperatura, batería, estado del tanque de la gasolina, luces tanto interiores como exteriores, direccionales o estados de error.

Esta tesis consta de una introducción, justificación, marco teórico, historia y descripción funcional como un primer acercamiento a los pormenores del proyecto. Se abordan temas como la necesidad que se satisface con un proyecto de estas características, la oportunidad de participar en un desarrollo de software a nivel grupal interaccionando con demás compañeros en diversos módulos así como la demostración de la comprensión y el uso de habilidades adquiridas como lo son el desarrollo de drivers, el manejo de protocolos de comunicación, el uso de sistemas operativos y el manejo de la ingeniería de software y sus elementos que conllevan y coadyuvan con los documentos descriptivos con los componentes prácticos de la producción de un proyecto de software formal.

El protocolo CAN es la piedra angular del proyecto al ser el esqueleto sobre el cual se basa. Todo el sistema de comunicación entre módulos funciona a base de mensajes de este protocolo y corona perfectamente el que fue posiblemente el punto más importante sobre el cual el programa académico puso énfasis durante su curso. Los sistemas operativos son representados por un Scheduler, el cual aunque básico, demuestra cabalmente el funcionamiento de un medio de agenda para la ejecución de tareas y los drivers que se desarrollaron son los cimientos para el funcionamiento del Microcontrolador con los componentes propios de un proyecto, como son el hardware con el cual interactúa para relacionarse con los estímulos del mundo tangible.

La teoría de este documento se basa en desarrollar los puntos del modelo de desarrollo de software llamado V-Cycle, que asemeja a una letra V. En estos pasos, los cuales son Requerimientos, Diseño, Implementación y Pruebas, son ampliamente detallados en cuanto a su composición básica, lo que cada uno de ellos aporta al proyecto, quienes participan en qué punto y sobre todo dejar unos información total y perfectamente comprensibles para posteriores implementaciones y correcciones a futuro.

Como Referencia se incluyen listados de los requerimientos y de las pruebas que fueron realizadas para comprobar el funcionamiento tácito de lo que se pedía en cada uno de los puntos de las necesidades básicas del proyecto.

A nivel práctico se manejan tablas de valores, fórmulas matemáticas, listado de variables, diagramas de flujo y de diseño, matrices de mensajes que en sus respectivos anexos conforman una fuente rápida y concisa de información a quien nos haga el honor de revisar o consultar este documento que tenemos la oportunidad de ofrecer al lector.

6

7

i. DiagramsDiagram 1_Project Block Diagram....................................................................................................21Diagram 2_Project Architecture diagram.........................................................................................22Diagram 3_Scheduler Operation......................................................................................................23Diagram 4_Scheduler Callback Function..........................................................................................24Diagram 5_Scheduler Main..............................................................................................................25Diagram 6_Key Debouncing task diagram........................................................................................43Diagram 7_CAN Message Handler task diagram..............................................................................44Diagram 8_CAN Transmit Message task diagram.............................................................................44Diagram 9_Low Voltage task diagram..............................................................................................45Diagram 10_Key Status task diagram...............................................................................................46Diagram 11_Screen Update task diagram........................................................................................47

ii. TablesTable 1_Thread assign into time......................................................................................................26Table 2_System task.........................................................................................................................27Table 3_System status flags.............................................................................................................27Table 4_LCD Clock and Frame Frequency.........................................................................................49Table 5_LCD Duty and Bias...............................................................................................................50Table 6_Message matrix table.........................................................................................................50

iii. Acronyms CAN - Controller Area Network. AUTOSAR - Automotive Open System Architecture. PLL - Phase Locked Loop. LIN - Local Interconnect Network. LCD - Liquid Crystal Display. BCM - Body Control Module. OSEK - Open Systems and their Interfaces for the Electronics in Motor Vehicles. MISRA - Motor Industry Software Reliability Association OS - Operative System

8

ContentAgradecimientos................................................................................................................................4

Acknowledgements............................................................................................................................4

Abstract..............................................................................................................................................5

Resumen............................................................................................................................................6

i. Diagrams....................................................................................................................................7

ii. Tables.........................................................................................................................................7

iii. Acronyms...................................................................................................................................7

1 Introduction.............................................................................................................................11

1.1 Justification......................................................................................................................12

1.2 Background.......................................................................................................................12

1.3 Project Objective..............................................................................................................15

1.4 Function Description........................................................................................................16

1.5 Requirements...................................................................................................................17

1.5.1 Speed........................................................................................................................18

1.5.2 Fuel level..................................................................................................................18

1.5.3 Battery voltage.........................................................................................................19

1.5.4 Temperature.............................................................................................................19

1.5.5 Humidity...................................................................................................................19

1.5.6 Key Position..............................................................................................................19

1.5.7 Crash Sensor.............................................................................................................19

1.5.8 Odometer.................................................................................................................20

1.5.9 Lights........................................................................................................................20

1.5.10 Low voltage operation..............................................................................................21

1.5.11 Fuel efficiency...........................................................................................................21

1.5.12 Failure Condition......................................................................................................21

2 Design.......................................................................................................................................22

2.1 Project Design Scope........................................................................................................22

2.2 Architecture......................................................................................................................23

2.3 OS Scheduler....................................................................................................................24

2.4 System tasks.....................................................................................................................28

2.4.1 Key Debouncing task................................................................................................29

2.4.2 CAN Message Handler task.......................................................................................29

2.4.3 CAN Transmit message task......................................................................................29

9

2.4.4 Low Voltage task.......................................................................................................29

2.4.5 Key Status task..........................................................................................................29

2.4.6 Screen Update task...................................................................................................30

2.4.7 Emulated EEPROM....................................................................................................30

3 Test...........................................................................................................................................31

3.1 Setup Test Case................................................................................................................31

3.2 Temperature Test Case.....................................................................................................32

3.3 Speed Test Case................................................................................................................33

3.4 Battery Voltage Test Case.................................................................................................34

3.5 Fuel Test Case...................................................................................................................35

3.6 Humidity Test Case...........................................................................................................36

3.7 Object Sensing Test Case..................................................................................................37

3.8 Lights Test Case................................................................................................................38

3.9 Exceptions Test Case........................................................................................................39

3.10 Low Voltage Test Case......................................................................................................41

3.11 Low Voltage Test Case......................................................................................................42

4 Conclusions..............................................................................................................................43

5 Appendix..................................................................................................................................44

5.1 Diagrams..........................................................................................................................44

5.1.1 Key Debouncing task................................................................................................44

5.1.2 CAN Message Handler task.......................................................................................45

5.1.3 CAN Transmit Message task.....................................................................................45

5.1.4 Low Voltage task.......................................................................................................46

5.1.5 Key Status task..........................................................................................................47

5.1.6 Screen Update task...................................................................................................48

5.2 ECU Configuration............................................................................................................49

5.2.1 PLL System Clock......................................................................................................49

5.2.2 Watchdog.................................................................................................................49

5.2.3 Timer Module...........................................................................................................49

5.2.4 CAN Driver Configuration.........................................................................................49

5.2.5 LCD Driver Configuration..........................................................................................50

5.3 Message matrix................................................................................................................51

6 References................................................................................................................................52

10

1 IntroductionThis work describes the proposed implementation of an embedded automotive cluster device. It focuses in the stages of implementation, from the client’s requirements to the test designed for the system validation. Following the V cycle for project development, the idea is track the stages paired with the requirements thru documentation and simple implementation. The document is divided in specific chapters designed to detail each step of the development process and make the reader follow along the same procedures the designers took while creating it.

The first step, requirements is all about the desired concept that a client is asked to deliver for the correct implementation of its idea, in this chapter the basics of the project are settled and is analyzed whether all requirements can be realized or if they need any change that leave both parties in an agreement.

The second chapter, design, elaborates in the way the requirements are put into different concept, in this case, engineering concepts, transforming words into accountable specs, units of measurements, flux diagrams or any other means an idea can be shifted into tangible solution.

The last chapter is the tests, and is in this chapter where the project is put to trial and is observed in each way it works and most desirable to find where it doesn't.

As an extra in the appendix section, there is a segment that intends to explain the basic configurations required for several of the most common and useful modules the project needs such as PLL configuration, CAN implementation, and the scheduler.

11

1.1 JustificationThe embedded systems specialization provided the tools on the most common elements used in the industry, such as designing and coding drivers, creating operative systems, implementing CAN, LIN, ZIGBEE, Embedded Linux and plenty more ideas. The next logical step was to make use of most of them and create a product that could evolve into a real piece of commercial technology.

A big commercial project requires several teams working together, but each one in a different module and they need to have a common agreement towards the same goal. This is where the architecture comes in to place (system architecture, software architecture, etc). This is the very first step of hopefully more to come, in the pursuit of developing a fully functional car created in the university by students.

It is an ambitious project for a small team made by students but a very rewarding one. Not only creates experience in the automotive industry, but enables creative thinking, problem solving and feeds the need an engineer has to fully understand the things in life. Also it builds towards some new generations that will update this code, this drivers and the whole project in hope of a better product and hopefully with the same expectations of their future colleagues.

1.2 BackgroundThis thesis is about a cluster for a car and the implementation of several modules. In this case, the CAN protocol is the main source of work, fused together with an operating system, with low level drivers and system architecture. It was designed to fulfill the subjects the specialization and put to test the skills learned through the courses.

Starting by configuration of modules, such as PLL, Inputs and Outputs, porting the operating system for one microcontroller to another, design of custom drivers (LCD), design of an architecture and the layers for the communication, generic functions that will be easily reusable for other projects, a CAN messages matrix for sending and receiving data efficiently, establishing constrains that not implementing them could lead to hazardous events and by far the most important thing, participation in a real life project that performs to the expectations of a real life consumer.

CAN is the most common implemented communication protocol in the automotive market. It provides solutions in diverse areas and enables reliable products to perform at expected conditions. The best way to understand it is to develop a product which relies on CAN protocol for its communication. Being that the specialization count among its files teachers that work in the industry, the decision for a CAN powered cluster as a first project was indeed the most adequate to begin a big project that will hopefully last for several generations of students. Together with the BCM, a first look at a car in functional state can be simulated and aloud the other modules to work from there.

The automotive networking modules were developed in order to create and establish coherence between all automobiles. The industry is quite concerned about the changes in technology and

12

they have understood the benefits of working together to achieve better results in a shared venture into the engineering of products. This doesn't mean all networks work the same way, however it's mostly intuitive and the development process are standardized.

The V Cycle represents a software development process that enables the code to be tested against specific sections of testing and thus developing a more complete and well-rounded software project.

The elements of the V Cycle are:

Requirements System Design Architecture Design Module Design

These 4 elements are combined to create the \ part of the V Cycle which belongs to the creative part of the process.

The Requirements are collected by analyzing the needs of the costumer. In this point the pertinent element is determining if the needs are indeed possible and how can they affect against them all. Is in this step where the agreements between costumer and developer must be reached to ensure both the desire product and the project to be are on page to end up being the same thing. The methods to obtain this data can vary from interviews, questionnaires, observations and simple cheap prototypes to finally set a user requirement document.

The System Design step follows and is where the engineer translates the user requirement document. This step works as a blueprint of the development phase. Any discovery that results out of this must be informed to the customer and submitted to further planning to ensure the corrections made to it does not affect the overall function of the project. Data structure, System organization are selected at this stage.

The Architecture Design continues the high end design of the project by selecting an operative system or protocol of development like OSEK or AUTOSAR. It is not always necessary to use an O.S. and it is mostly dependable of the complexity of a project, however, the usage of a protocol like AUTOSAR forces the development to follow established set of rules that allows for future expansions and revisions to a well-developed and documented architecture. The basic elements of architecture are the layers that separate the code into well divided modules.

Module Design is where the code is almost being written, creating pseudo code in the selected module, being drivers, services, abstraction, Run Time Environment, application just to name a few. The variables are defined and the code is measured to fit in the desired microcontroller that was selected in the Requirements step.

The low part of the V cycle is the code itself and has no other element that mirrors it.

13

The corresponding 4 elements of the V Cycle that matches the creative part or / for the testing procedure are.

Unit Test Integration Test Functional Test User Acceptance Test

The Unit Test provides exhausting testing to the individual modules of code. Each module shall behave as expected and perform accordingly to the requirements in the individual form that are in this precise moment. Testing can be developed to ensure the correct functioning of the modules since most of the inputs maybe in other modules. This individual unit tests are performed by the same developer of the code.

The Integration Test merges all of the modules and performs the same test but in a new way since the modules shall interact with each other without the aid of external code. Some hardware inputs or computer triggered interrupts can still be implicated in the testing. These tests are mostly realized by a group of developers.

Functional Testing is performed by specialized engineers that are interested in the overall behavior of the product. They match the requirements of the first step and validate that all of the needs are satisfied. They also realize tests that are not in the requirements, and aim to destroying the product, by any means possible, to test endurance, portability, usability, stress, or bugs. The most important point in this step is not to test whether the system work as expected, but instead to ensure the system does not fail when the unexpected happen.

User Acceptance Test is the last of the V-cycle steps and as its name indicates, the user has the opportunity to test the product and validate by his or her own means that the delivered project performs as expected and satisfies all the needs that the user requirement document commanded at the beginning of the life cycle.

This is an extended view of a complete V-Cycle that is widely used in the software industry. For the sake of this project, the developers opted for a reduced V-Cycle that does not impact in the times estimated for this project. Requirements remain the same; the design is compressed in one section of design, following all the specific needs of design. Coding is the same but another step is added, a compilation step when the developers have the opportunity to comply with set of code rules, in this case MISRA rules. The last step, Testing, is again merged in one big step only focusing in the functional test for the documentation, however, unit and integration testing was done while developing the code.

14

1.3 Project ObjectiveThere are reasons to make things happen. Innovation, improvement, security, business or even a hobby, the study of a specialization is a mixture of all those things. When a career provides the basic tools for personal development and growth, it falls short of the required skills for a more specific work. The study of a subject applied in more technical ways, increments the knowledge from another perspective and gives the skill to interact with the problems in more viable ways.

In the embedded systems specialization the subjects were plenty and very interesting. From single drivers development, usage of network communication protocols such as LIN, CAN, or Zigbee, implementation and development of a variety of several types of operative systems, understanding and application of software engineering and software architecture.

All to be mixed in a final project where all techniques are combine to form a functional piece of a big environment to be created over the years. The plan calls for a very long project that spans from several generations each year developing a different module of a real car, with everything developed and coded by students of the university.

This project got the opportunity to start with such task and its course of action it is to develop the cluster for the car. The basic task this cluster has is to report the signals to the driver and provide him with the security of knowing the status of the car. Besides it controls the lights system (both interior and exterior lights and beams) also being represented in the screen.

The project itself represents a very good implementation of the skills the specialization brought to the table, basing the communication in the CAN protocol, using an operative system to maintain control of the operations, designing custom made drivers for external devices like the LCD screen for the cluster, etc.

It ensures the topics are not lost on simple theory, but force its way to a tangible application that can be updated and modified in an infinite number of ways. Along as the work is done, opens up possibilities that before the year seemed unrealistic and motivates to continue research in the subject.

Obtaining a degree is also one of the biggest benefits the specialization program has offered to us. It let us be recognized in the industry and works as a presentation card whenever our services can be required. This opportunity provides advantages in a very competitive but rewarding world.

15

1.4 Function DescriptionBased on the Spec of CAN 2.0 high speed, the cluster performs on a Freescale microcontroller, of the S12 family, with a scheduler O.S., an integrated LCD (to be upgraded in the foreseeable future) and for the moment, installed on a demo briefcase together with the BCM project where it is displayed in a demonstration state, simulating the signals received by the BCM through the CAN communication protocol.

16

1.5 RequirementsAll projects shall start somewhere. Starting with a set of requirements it’s a very good idea. Indeed in the industry this shall be the only way a project starts. Having a set of requirements make people comprehend the project they are about to begin in certain ways that a simple idea of their needs would not be sufficient. It is supposed they want to build a house, and start by thinking, which are the needs? Some bricks, wood, glass, tools, cement, wires, tiles, screws, a wrench, and those will not be enough. Nails are needed? How many nails will be sufficient? A hammer of a certain type is needed as well. Are the results with this little planning good enough for the customer? That’s why in any project is a must to establish the rules prior to begin any work. The idea in the head of one person is miles away from the idea of another person head. A document where the desired ideas of the customer are understood and comprehended make both parties reach an agreement fast enough and in a satisfactory way

For the project it was required to do a dashboard for the car that is going to be designed over the courses of the Embedded Systems specialization. This project is working along the body team, that is working with the signals the cluster is about to receive. The basic premise of the cluster is to display the vital information that the driver needs at any given time to ensure the safety of the trip the passengers are making.

The first approach is to lay down the basics. What does a driver needs when in the driver seat?

1. Speedometer.2. Fuel tank3. Temperature sensor4. Odometer5. Battery6. Lights7. Humidity8. Position of the switch9. Crash sensor

The next concern is how are the signals going to be managed? There is a need for a protocol to send and receive this information. The automotive industry already has a well-established answer for this, the CAN protocol is used for these messages to be delivered back and forth between modules.

Then the next step is to choose a microcontroller for the project. There is a need for a microcontroller that supports CAN communication and preferable already has a LCD screen to have in one board our cluster without the necessity of external components. The HY64 microcontroller, of the S12 family was chosen based on the characteristics it provides. Special thanks to Freescale for providing the demo board for the project.

For the CAN protocol to work, an operating system is needed to manage all functions and messages. Several options were considered and given the fact that there is already a

17

microcontroller, it was opted for an OS that it was knew it could work with very few modifications, porting the scheduler of the teacher, M.C. Abraham Tezmol, from one member of the S12 family to another.

A matrix of requirements is needed in order to set the precedence of needs. It can be divided in two very specific sections: Incoming messages and Outgoing messages.

Incoming messages:

1. Speed2. Fuel level3. Battery voltage4. Temperature5. Humidity6. Key position7. Crash sensor8. Odometer

Outgoing messages:

1. Lights

In this segment, the lights are a different matter since they have different sources of light. There are interior lights, exterior lights and the beams, which are divided between low beam and high beam, for different environmental conditions. Also, the high beam is considered as well an optical horn, which is a signal that is used while driving to alert other vehicles of situations pertinent to the road.

Here, the full list of requirements:

1.5.1 Speed (CLUS010) Cluster shall display SPEED VALUE segment and Km/h segment on Screen. (CLUS011) Speed value shall be defined in Km/h. (CLUS012) Speed value shall be in range of 0 - 120 Km/h. (CLUS013) Speed value resolution shall be of decimal value (0.5 Km/h). (CLUS014) The speed value shall always be displayed on the screen. Except when the proximity

measure is needed. (CLUS015) The Km/h segment shall always be ON. Except when the proximity measure is needed.

1.5.2 Fuel level (CLUS020) Cluster shall display FUEL LEVEL segment, FUEL segment and LITERS segment on Screen. (CLUS021) Fuel value shall be defined in Liters. (CLUS022) Fuel value shall be in range of 0 to 45 Liters (normal tank). (CLUS023) Fuel value shall be represented inside LEVEL (6 segments), Reserve Fuel 5 liters (1

segment) and Fuel 40 liters (5 segment). (CLUS024) When the Fuel value is in reserve the Screen segment FUEL shall start blink every 500ms. (CLUS025) The LEVEL segment shall always be ON depending of the Fuel value. (CLUS026) The FUEL segment shall always be ON. (CLUS027) The LITERS segment shall always be ON

18

1.5.3 Battery voltage (CLUS030) Cluster shall display Battery VOLTAGE LEVEL segment and SYSTEM VOLTAGE segment on

Screen. (CLUS031) The battery Voltage (12V) shall be represented within 6 segment steps (2V each). (CLUS032) The LEVEL segment shall always be ON depending of the battery value. (CLUS033) The SYSTEM VOLTAGE segment shall always be turned on.

1.5.4 Temperature (CLUS040) Cluster shall display Ambient TEMPERATURE VALUE segment, TEMP segment and ⁰C

segment on Screen. (CLUS041) Temperature value shall be defined in ⁰C degrees. (CLUS042) Temperature value shall be in range of 0 - 99.9 C degrees. (CLUS043) Temperature resolution shall be of decimal value (0.5 ⁰C degrees). (CLUS044) The temperature value shall alternate with the humidity value every 5 seconds. (CLUS045) While the temperature value is displayed the TEMP and ⁰C segment shall be turned on.

1.5.5 Humidity (CLUS050) Cluster shall display Environment HUMIDITY VALUE segment and OUTSIDE segment on

Screen. (CLUS051) Humidity value shall be defined in percentage (%). (CLUS052) Humidity value shall be in range of 5% - 95%. (CLUS053) Humidity value resolution shall be of 10%. (CLUS054) The humidity value shall alternate with the temperature value every 5 seconds. (CLUS055) While the humidity value is displayed the OUTSIDE segment shall be turned on.

1.5.6 Key Position (CLUS060) The key Status shall control the handling of power of the BCM. (CLUS061) The key Status shall have two values, key status ON and key status OFF. (CLUS062) If Key Status OFF, the ECU shall be capable of turning off the display, while still

functioning in listen mode. (CLUS063) If Key Status ON, the ECU shall be capable of turning on the display. (CLUS064) When Key Status OFF, the system shall respond a light request, by turning on the cluster

and the display to send the message of the lights. (CLUS065) When a “Key Off” events occurs, the ECU shall save in the EEPROM the current value of

the odometer, maximum speed raised during the last “Key On” cycle and the value of the last Humidity calculation.

1.5.7 Crash Sensor (CLUS070) Cluster shall display OBJECT SENSING VALUE segment and DISTANCE segment on Screen. (CLUS071) Object sensing value shall be in meters. (CLUS072) Object sensing value shall be in range of 0.1 to 10.0 meters. (CLUS073) Object sensing resolution shall be of decimal of meters (0.5 meter). (CLUS074) OBJECT SENSING VALUE shall be displayed instead of SPEED VALUE only when the value

is minor to 2 Meters. In example for parking. (CLUS075) When displaying object sensing the DISTANCE segment shall be always turned on.

19

1.5.8 Odometer (CLUS080) Cluster shall display GPS POSITION VALUE (Latitude & Longitude) segment, ODOMETER

VALUE segment, ODO segment and KM segment on Screen. (CLUS081) Distance odometer value shall be defined in Kilometers. (CLUS082) Distance odometer value shall be in range of 0 - 99999.5 Km (CLUS083) Distance odometer resolution shall be of decimal value (0.5 Km). (CLUS084) System shall store distance odometer and be modified by the GPS new position. (CLUS085) When displaying distance odometer the ODO segment and KM segment shall be always

turned on. (CLUS086) GPS position shall be received from GPS. (CLUS087) POSITION VALUE shall be displayed only when the SPEED VALUE is 0 Km/h. (CLUS088) POSITION VALUE and ODOMETER VALUE shall be alternated to be displayed every 2

seconds. (CLUS089) Latitude and Longitude are still pending to be defined.

1.5.9 Lights (CLUS090) Cluster shall display Buttons for INTERIOR LIGHT segment on Screen. (CLUS091) When the interior lights button is on the INTERIOR LIGHT segment shall be turned on. (CLUS092) Cluster shall display Buttons for EXTERIOR LIGHT segment on Screen. (CLUS093) When the exterior lights button is on the EXTERIOR LIGHT segment shall be turned on. (CLUS094) Cluster shall display Stalk position switches with LEFT STALK segment and RIGHT STALK

segment on Screen. (CLUS095) When displaying the LEFT STALK segment it shall blink every 500ms. (CLUS096) When displaying the RIGHT STALK segment it shall blink every 500ms. (CLUS097) Cluster shall display Stalk position switches with LOW BEAM segment on Screen. (CLUS098) Cluster shall display Stalk position switches with HIGH BEAM and OPTICAL HORN

segment on Screen. (CLUS099) Stalk position switch shall have the following, Turn Left, Turn Right, High Beam, Low

Beam and Optical Horn. (CLUS100) If the “Turn left” switch is pressed, shall be not possible to have the “Turn right” switch

pressed (and vice versa). (CLUS101) If the “Optical Horn” switch is pressed, shall be not possible to have the neither High nor

Low beam switches pressed (and vice versa).

There are also some special needs requirements, pertinent to the overall performance of the system. It is needed to constantly maintain monitoring of the voltage to ensure the values that the ECU is reporting are real. Besides, the fuel efficiency shall be taken in to account to provide the user with enough data to plan the driving and charge fuel based on a date and not only on the level. Also, a failure condition shall be presented in order to avoid further damages to the car, disabling operation and saving other modules that are not yet damaged.

20

1.5.10 Low voltage operation (CLUS110) System shall identify a low voltage condition from the Voltage input manager (Body). (CLUS111) System shall display a signal of Low Voltage Operation on the screen when a Low

Voltage condition is detected. (CLUS112) The Low Voltage Operation signal shall be the only thing displayed on the screen during

the Low Voltage Operation. (CLUS113) System shall store the last value of the Odometer into the EEPROM when the Low

Voltage Condition is detected.

1.5.11 Fuel efficiency (CLUS120) The Cluster shall be able to shown the odometer by taking this value from the GPS

(inside of the ECU). With this value and the value of the fuel level, the Cluster will calculate the fuel efficiency of the car and this value will be shown in the screen (always that the key Status = “ON”).

(CLUS121) The FUEL EFFICIENCY VALUE segment and L/100KM segment shall be displayed only when the key Status = ON for at least 5 seconds.

(CLUS122) Fuel efficiency shall be defined in liters per 100 kilometers L/100Km. (CLUS123) Fuel efficiency shall be in range of 0 - 999.5 L/100Km. (CLUS124) Fuel efficiency resolution shall be of decimal value (0.5 L/100Km).

1.5.12 Failure Condition (CLUS130) If a failure condition is received, this information shall be shown in the screen, "ERROR".

21

2 DesignThis chapter reviews the design concepts followed for the project development, including the Software Architecture, Operating system and Project tasks and leaves the door open for further implementation to comply the abstraction architecture used.

2.1 Project Design ScopeThe MCU proposed is a Freescale DEMO9S12HY64 16 bits board which belongs to the S12 microcontroller family, the same used along the specialization. This board includes a delimited segments LCD screen; this means we have to set our requirements to the only available segments.

Due to the limitation of have a module which controls the DC power for the project, the key off event doesn’t set the MCU to the low voltage stage, so we just emulate the states inside a state machine and the transitions are made from input signals from the BCM module.

The BCM module has the task to check any condition of the AC line, and also it receives the key events. The Cluster also checks the Stalk/Light switches and report state to the BCM module as shown in the Diagram 1.

Diagram 1_Project Block Diagram

The CAN message according to the requirements are shown in the CAN message table on appendix section.

22

2.2 ArchitecturePart of the design process of the project consist in define the software Architecture to identify the major software components and their interactions. A well-defined architecture gives us the abstraction between the software components to be migrated to other platforms with the minimum effort. Also adding components for future development will be an easy task given the well establishes foundation. The architecture proposed follow an AUTOSAR based orientation shown on the next diagram, desirable architecture approximation should be oriented to the fulfillment of AUTOSAR standard, due to the project objective only a standard based architecture is used, conserving the reusability and scalability of code.

Diagram 2_Project Architecture diagram

The project Drivers required specific configuration shown on the appendix section. This document focus on the develop cycle of the whole project, not in the specific implementation of the components and drivers, that why most of this information are compounded as appendixes.

23

2.3 OS Scheduler.The proposed operating system is a full cooperative non-preemptable scheduler, it uses a time base to increment a scheduler counter which is used to assign a thread of execution, The threads consists into a group of task configured into the scheduler table to be executed every determinate time.

The scheduler time base is called OS tick, which is the slide of time reserved to every group of task into a thread to execute. The common used process to generate the system time is a Real Time Counter, but into the proposed board is used a channel of the timer module configured in output compare mode to generate the time. This channel counts up to a programmable value, after it reaches the count it will generate an interrupt service request modifying the scheduler counter. Every OS tick the scheduler counter shall be increased.

Diagram 3_Scheduler Operation.

24

The scheduler task decides which thread will be executed. Every ISR a scheduler callback will be issued; where, besides of modifying the counter, it will check the iterations based on the OStick to generate the desired time for the thread that has to be executed. The callback function is shown in the Diagram 4_Scheduler Callback Function. To generate the different time threads, masks are applied to the modified Scheduler counter, and depending of some bit transitions the thread’s time counter are incremented. The callback defines 3 basic threads from which other threads are derived. 100ms thread derived from count of 1ms threads, 50ms thread derived from count of 2msA thread and 10ms thread derived from count 2msB thread. This arrangement assures core will have equal task loading across time.

1ms thread (basic) -> 100ms thread (derived). 2msA thread (basic) -> 50ms thread (derived). 2msB thread (basic) -> 10ms thread (derived).

Project designated OS tick is configured as shown below. Refer to section Error: Reference sourcenot found To more details of MCU project configuration.

OStick=500us (1).

Diagram 4_Scheduler Callback Function.

25

Now is time of the Scheduler main function to execute the thread assigned into the callback time count, this function run inside a infinite loop where checks the activation of the threads thru the time. In the case that no thread has to be executed in a slice of time, the background task will be executed, then the scheduler main function runs again and checks if there is a thread to be executed, now if there is a thread to be executed the function run the task inside the thread, if not it will run the background task again and repeats inside the loop. This process is shown in the Diagram 5_Scheduler Main.

Diagram 5_Scheduler Main

Due to thread derived from another thread inside a slice of time, two threads may be executed one after another, for example: after 100 counts of 1ms thread, the 100ms thread will be selected for execution, but the 1ms thread condition will happen too so the Scheduler main function will execute them both. The activation of threads into the time is shown in the Table 1_Thread assigninto time. Where can be appreciate it that no threads will overlap inside time. Only one part of the time is show, for the complete time table, refer to extra documentation of the project.

26

OS_Tick Scheduler Thread IDTime

system(ms)Decimal

Hex 1ms 100ms 2msA 50ms 2msB 10ms

0 0x0 - - - - - - 0.0

1 0x1 Task_1MS - - - - - 0.5

2 0x2 - - Task_2MS_A - - - 1.0

3 0x3 Task_1MS - - - - - 1.5

4 0x4 - - - - Task_2MS_B

- 2.0

5 0x5 Task_1MS - - - - - 2.5

6 0x6 - - Task_2MS_A - - - 3.0

7 0x7 Task_1MS - - - - - 3.5

8 0x8 - - - - Task_2MS_B

- 4.0

9 0x9 Task_1MS - - - - - 4.5

10 0xA - - Task_2MS_A - - - 5.0

11 0xB Task_1MS - - - - - 5.5

12 0xC - - - - Task_2MS_B

- 6.0

13 0xD Task_1MS - - - - - 6.5

14 0xE - - Task_2MS_A - - - 7.0

15 0xF Task_1MS - - - - - 7.5

16 0x10 - - - - Task_2MS_B

- 8.0

17 0x11 Task_1MS - - - - - 8.5

18 0x12 - - Task_2MS_A - - - 9.0

19 0x13 Task_1MS - - - - - 9.5

20 0x14 - - - - Task_2MS_B

Task_10MS 10.0

Table 1_Thread assign into time.

The task configured for the project inside the time threads are defined into the next chapter based on the user requirements.

27

2.4 System tasksIn this section the task will be defined based on the system requirements. Depend on the task priority will be put in different time threads.

The system status flags are the Low System Voltage and the Key Status. The tasks check these status variables.

Most important task depends on the time execution constraint.

Task Name Periodic Execution Dependency Function Name ThreadWatchdog 2ms No Dependency vfnCOPWatchdog_Reset TASKS_2_MS_B

Debouncing 2ms Low Voltage vfnGPIO_Debouncing TASKS_2_MS_B

Receive Data 2ms No Dependency vfnCAN_MessageHandlerTASKS_2_MS_

ATransmit Data 10ms Low Voltage vfnCAN_TransmitMessage TASKS_10_MSLow Voltage 10ms No Dependency vfnLOWVOLTAGEstatus TASKS_10_MSKey Status 10ms Low Voltage vfnKEYSTATUSstatus TASKS_10_MSLed Life Bit 100ms No Dependency vfnGPIO_LEDFlash TASKS_100_MS

Update LCD Screen 100ms1. Low Voltage2. Key Status vfnLCDrefreshstatus TASKS_100_MS

Data BackUp 10min Low Voltage - -Table 2_System task.

Global Variables Lvl Description

gu8KEYSTATUSflag0 Key off (Default)1 Key On

gu8LOWVOLTAGEflag0 Normal Mode (Default)1 Low Voltage Mode

gu8CANTIMEOUTflag0 Time Out Off (Default)1 Time Out On

gClusterActualData.u8Keystatus0 Key Off Message Status (Default)1 Key On Message Status

gClusterActualData.u8LowVoltageStatus0 Normal Mode Message Status (Default)1 Low Voltage Mode Message Status

gClusterActualData 0 DefaultSTALKACTUALVALUE 0 Default

gu8ScreenStatusflag0 Turn On (Default)1 Turn Off

Table 3_System status flags

28

2.4.1 Key Debouncing taskThe purpose of this task is to identify the input of the project’s switches to the digital circuit; the signal will need to be debounced so a single press doesn’t appear like multiple presses. The basic idea is to sample the switch signal at a regular interval and filter out any glitches. The function uses a counter to time how long the switch signal has been in a valid state. If the signal has been continuously for a set amount of time, then, it is considered pressed and stable.

The task time cycle is 2ms according to the Table 2_System task. The counter of valid key press is 10 counts. The key time for a stable signal is 20ms. The Validated stalk information is updated on this time.

Refer to Diagram 6_Key Debouncing task diagram.

2.4.2 CAN Message Handler taskThis task polls the flag for a new message from the DCM. When a new message has been received, the information of the cluster data is updated.

The task includes a time out CAN communication, it set an event count when a message has not been received, meaning that there was an error on the CAN line and set a flag to set a message on the screen. The count is set to 500, resulting in a 1s CAN time out from the task time cycle.

Refer to Diagram 7_CAN Message Handler task diagram.

2.4.3 CAN Transmit message taskThis task sent the valid data from the stalk position. The task cycle time is 10ms, it is not found on a less time thread according to design, the signals of the stalk position are not high priority.

Refer to Diagram 8_CAN Transmit Message task diagram.

2.4.4 Low Voltage taskThe task identifies a message from the BCM module, which senses the voltage, to set up a state of low voltage on system. When a Low Voltage status is identify, a flag is set and a routine to save system information on emulated EEPROM is launched. When a Normal Voltage status is identified, the flag is set and the system is forced to a reset condition. The initialization function will restore the system information from the emulated EEPROM.

Refer to Diagram 9_Low Voltage task diagram.

2.4.5 Key Status taskThe Key status task identifies a Key switch ON/OFF event. On a Key ON event, a status flag is set and the entire Cluster data is set to default value, next, the information from the emulated EEPROM is restored to the status variables. On a Key OFF event, the status flag is clear, and the status variables are stored on the emulated EEPROM.

Refer to Diagram 10_Key Status task diagram.

29

2.4.6 Screen Update taskThis task will update the information on the LCD screen, on the stalk valid data and the information from the BCM module. It will read the flag status to identify the system state and display the right information on screen.

Refer to Diagram 11_Screen Update task diagram.

2.4.7 Emulated EEPROMThe segment defined as emulated EEPROM could not be developed due to time constrains. In the design of the project, an emulated EEPROM was included to ensure the data could be restored after a failure or after a power on reset. Since the project was designed without the turn off option, there is no need to re obtain values from the nonvolatile memory.

The original design for the EEPROM was implemented as a virtual segment thanks to options presented by the demo board itself. The virtualization of the EEPROM was to be implemented as a segment in the flash memory of the ECU. Selecting specific sizes to resemble a page (all EEPROM behave in a way that pages of data are accessed at the same time, in power of two, (e. g. 2, 4, 8, 16, 32 bytes) the need to create a sampling data archive that enables scheduling of respective variables.

With the aid of the table 3, the necessary flash space was to be select to accommodate the corresponding variables. Since not all data is required in a must situation, there was no necessity to incorporate them all. In this case, only the values for the odometer, last humidity value and top speed in last key on cycle. Whenever the opportunity, due to error, turn off or just precautionary measure, this values were to be written to the flash memory and then updated to the main program when the system required them.

In future implementations of this project is required to further increase the reaching of the EEPROM, validating more signals such as brake, fuel consumption, temperature and key status just to name a few.

30

3 TestThe testing phase is often overlooked as if was not important in the development cycle of a new product. In fact, while some people do not consider a proper testing cycle, testing is done in every stage of the development by simply revisions of a person’s idea, line of code, schematic or diagram. Testing can solve most of the problems before the project evolves into another stage and hopefully avoiding a product to reach production stage with a flaw so big it make the product worthless to the public causing important loses, both by money and jobs.

Testing also has its own special V-cycle, annexed to each step of the overall development. Testing can be made only to a little software module, or to a complete code. Testing can be done to a product in development or to a fully functional prototype. The amount of testing is often a lot less than what it should be, but companies and even single developers and producing are taking note of the benefits from having a good testing procedure next to the production of their projects.

For a big project, is expected to have a different team providing the testing work as is preferred to have someone not familiarized in the deeps of the project. This could lead to somehow obviate some of the flaws or making a quick fix for a problem not to arise. Problems are expected to surface, if they don’t, then some of the procedure is not right, no project is flawless and should be at this stage when the problems are fixed.

For the cluster project, it was decided to do functional testing. Since is a 95% software project, the testing was to be applied to the specific functions of the code and only at the end, to test the project up and running.

For the functional code, a special CAN message was sent. In loopback mode, this message was sent and updated the values of all the cluster modules to shift their values from all of their lows to all of their highs ensuring all the range was covered.

For the complete project, a demo briefcase was constructed to fit both this project and its sister project, the BCM module, to have both systems working together sending and receiving CAN messages in a real CAN environment. The signals were reproduced with switches and the testing was done as if it was in a car.

Next, the test specs and the actual results produced by the testing activities are found.

3.1 Setup Test CaseRequirements:

Connect the ECU to the power source. Open CodeWarrior 4.7 and load the test project. Compile and download project into ECU.

Objective:

31

Load the correct project and set the necessary data to start testing.

Prerequisites:

Having the code ready to compile and a computer with Codewarrior 4.7.

Expected Result:

Step 1 Verify the ECU is turned on and signals are displayed at the LCD screen. Step 2 End of Test Case.

Actual Result:

Step 1 The ECU is turned on and the info is displayed. Step 2 End Of Test Case.

3.2 Temperature Test Case

Requirements:

Cluster shall display Ambient TEMPERATURE VALUE segment, TEMP segment and C segment on Screen.

Temperature value shall be defined in C degrees. Temperature value shall be in range of 0 - 99.9 C degrees. Temperature resolution shall be of decimal value (0.1 C degrees). The temperature value shall alternate with the humidity value every 5 seconds. While the temperature value is displayed the TEMP and C segment shall be turned on.

Objective:

Verify the LCD cluster display the temperature in the expected values.

Prerequisites:

Setup Test Case. Enable the Test Function with CAN messages in random values.

Expected Result:

Step 1 Verify the Temperature value segment TEMP and the ⁰C label are displayed on screen

Step 2 Verify temperature is displayed in Celsius degrees Step 3 With aid from the CAN random values, verify temperature is displayed from 0 C° to

99.9°C with 0.1 increments Step 4 Verify that each 5 seconds, the temperature value is shifted with the humidity value

32

Step 5 When temperature is displayed, the label segments are turned on Step 6 End Of Test Case

Actual Result:

Step 1 The segments are displayed correctly Step 2 Temperature is displayed in Celsius degrees Step 3 The Values are displayed correctly Step 4 The value is shifted each 5 seconds Step 5 The segments TEMP and the C label are turned on Step 6 End of Test Case

3.3 Speed Test CaseRequirements:

Cluster shall display SPEED VALUE segment and KM/H segment on Screen. Speed value shall be defined in Km/h. Speed value shall be in range of 0 - 120 Km/h. Speed value resolution shall be of decimal value (0.1 Km/h). Speed value shall be received from the GPS module. The speed value shall always be displayed on the screen. Except when the proximity

measure is needed. The KM/H segment shall always be ON. Except when the proximity measure is needed.

Objective:

Verify the LCD cluster display the speed in the expected values

Prerequisites:

Setup Test Case Enable the Test Function with CAN messages in random values

Expected Result:

Step 1 Verify the Speed value segment SPEED and KM/H label are displayed on screen Step 2 Verify the speed is displayed in KM/H Step 3 With aid from the CAN random values, verify speed is displayed from 0 KM/H to

127.5 KM/H with 0.5 increments Step 4 Verify that the value is always displayed, except when the proximity meter is

displayed Step 5 When Speed is displayed, the label segments are turned on Step 6 End Of Test Case

Actual Result:

33

Step 1 The segments are displayed correctly Step 2 Speed is displayed in KM/H Step 3 The Values are displayed correctly Step 4 The value is always present except when the Proximity meter display the

information Step 5 The segments SPEED and KM/H are displayed Step 6 End of Test Case

3.4 Battery Voltage Test CaseRequirements:

Cluster shall display Battery VOLTAGE LEVEL segment and SYSTEM VOLTAGE segment on Screen.

The battery Voltage (12V) shall be represented within 6 segment steps (2V each). The LEVEL segment shall always be ON depending of the battery value. The SYSTEM VOLTAGE segment shall be always.

Objective:

Verify the LCD cluster display the Battery Voltage in the expected values.

Prerequisites:

Setup Test Case Enable the Test Function with CAN messages in random values.

Expected Result:

Step 1 Verify the Battery Voltage value segment VOLTAGE LEVEL and SYSTEM VOLTAGE label are displayed on screen

Step 2 Verify the Battery Voltage is displayed with an array of 6 bars, each one representing 2 V of the possible 12 V.

Step 3 With aid from the CAN random values, verify Battery Voltage is displayed from 0 V to 12V. with 2V increments

Step 4 Verify that whenever there is battery, the label VOLTAGE LEVEL is displayed Step 5 Verify that when on power, the label SYSTEM VOLTAGE is on Step 6 End Of Test Case

Actual Result:

Step 1 The segments are displayed correctly Step 2 The Battery Voltage is displayed in 6 bars Step 3 The Values are displayed correctly, each bar representing 2 V, conforming the 12

Volts

34

Step 4 The Label is displayed accordingly Step 5 The values is displayed when the power is on Step 6 End of Test Case

3.5 Fuel Test CaseRequirements:

Cluster shall display FUEL LEVEL segment, FUEL segment and LITERS segment on Screen. Fuel value shall be defined in Liters. Fuel value shall be in range of 0 to 45 Liters (normal tank). Fuel value shall be represented inside LEVEL (6 segments), Reserve Fuel 5 liters (1

segment) and Fuel 40 liters (5 segment). When the Fuel value is in reserve the Screen segment FUEL shall start blink every half of

second time. The LEVEL segment shall always be ON depending of the Fuel value. The FUEL segment shall always be ON. The LITERS segment shall always be ON.

Objective:

Verify the LCD cluster display the fuel in the expected values

Prerequisites:

Enable the Test Function with CAN messages in random values

Expected Result:

Step 1 Verify the Fuel Level value segment, Fuel label and Liters label are displayed on screen

Step 2 Verify the fuel is displayed in Liters Step 3 With aid from the CAN random values, verify fuel is displayed from 0 Liters to 45

Liters Step 4 Verify that each segment represents for 8 liters, except the first one, the reserve,

only holds 5 liters Step 5 When the fuel is in the first segment (0 to 5 liters) verify that the segment FUEL

blinks every half second Step 6 Verify the Level segment is always on, except when there is no fuel Step 7 Verify that the FUEL segment is on, except when on reserve or no fuel at all Step 8 Verify that the LITERS segment is always on Step 9 End of Test Case

Actual Result:

35

Step 1 The segments are displayed correctly Step 2 Fuel is displayed in Liters Step 3 The Values are displayed correctly Step 4 Segment 1 goes from 0 to 5, segment 2 goes from 6 to 13, segment 3 goes from 14

to 21, segment 4 goes from 22 to 29, segment 5 goes from 30 to 37 and segment 6 goes from 38 to 45

Step 5 The segment is blinking Step 6 Segment is always on when fuel is at least 1 liter Step 7 Segment is on Step 8 LITERS segment is always on Step 9 End of Test Case

3.6 Humidity Test CaseRequirements:

Cluster shall display Environment HUMIDITY VALUE segment and OUTSIDE segment on Screen.

Humidity value shall be defined in percentage (%). Humidity value shall be in range of 5% - 95%. Humidity value resolution shall be of 10%. The humidity value shall alternate with the temperature value every 5 seconds. While the humidity value is displayed the OUTSIDE segment shall be turned on.

Objective:

Verify the LCD cluster display the humidity in the expected values.

Prerequisites:


Expected Result:

Step 1 Verify the Humidity Segment and the Outside Label are displayed Step 2 Verify humidity is displayed in percentage (%) Step 3 With aid from the CAN random values, verify humidity is displayed from 5%° to 95%

with 5% Step 4 Verify that each 5 seconds, the humidity value is shifted with the temperature value Step 5 When temperature is displayed, the label segments are turned on Step 6 End Of Test Case

Actual Result:

Step 1 The segments are displayed correctly

36

Step 2 Humidity is displayed in Percentage (%) Step 3 The Values are displayed correctly Step 4 The value is shifted each 5 seconds Step 5 The segment Humidity and OUTSIDE label are displayed Step 6 End of Test Case

3.7 Object Sensing Test CaseRequirements:

Cluster shall display OBJECT SENSING VALUE segment and DISTANCE segment on Screen. Object sensing value shall be in meters. Object sensing value shall be in range of 0.1 to 10.0 meters. Object sensing resolution shall be of decimal of meters (0.1 meter). OBJECT SENSING VALUE shall be displayed instead of SPEED VALUE only when the value is

minor to 2 Meters. In example for parking. When displaying object sensing the DISTANCE segment shall be always turned on.

Objective:

Verify the LCD cluster display the proximity measure in the expected values

Prerequisites:


Expected Result:

Step 1 Verify the Object Sensing Segment and the DISTANCE Label are displayed Step 2 Verify Object Sensing is displayed in meters Step 3 With aid from the CAN random values, verify the Object Sensing value goes from

0.1M to 2M with increments of 0.1M Step 4 Verify that Object Sensing segment is displayed instead of the Speed segment Step 5 Verify that when the Object Sensing value is being displayed, the label DISTANCE is

turned on Step 6 End Of Test Case

Actual Result:

Step 1 The segments are displayed correctly Step 2 Object Sensing measure is displayed in meters Step 3 The Values are displayed correctly Step 4 Object Sensing value is displayed instead of Speed Step 5 The Label is being displayed Step 6 End of Test Case

37

3.8 Lights Test CaseRequirements:

Cluster shall display Buttons for INTERIOR LIGHT segment on Screen. When the interior lights button is on the INTERIOR LIGHT segment shall be turned on. Cluster shall display Buttons for EXTERIOR LIGHT segment on Screen. When the exterior lights button is on the EXTERIOR LIGHT segment shall be turned on. Cluster shall display Stalk position switches with LEFT STALK segment and RIGHT STALK

segment on Screen. When displaying the LEFT STALK segment it shall blink every half of second. When displaying the RIGHT STALK segment it shall blink every half of second. Cluster shall display Stalk position switches with OPTICAL HORN segment on Screen. Cluster shall display Stalk position switches with LOW BEAM segment on Screen. Cluster shall display Stalk position switches with HIGH BEAM segment on Screen.

Objective:

Verify the LCD cluster display the lights in the expected situations

Prerequisites:


Expected Result:

Step 1 Verify the LCD display the icons for Interior Light, Exterior Light , Left Stalk, Right Stalk, High Beam and Low Beam

Step 2 Verify that when the interior lights are on, the INTERIOR LIGHT segment is turned on

Step 3 Verify that when the exterior lights are on, the EXTERIOR LIGHT segment is turned on

Step 4 Verify that when the left stalk is on, the LEFT STALK segment is turned on and blinking every half second

Step 5 Verify that when the right stalk is on, the RIGHT STALK segment is turned on and blinking every half second

Step 6 Verify that when the interior lights are on, the INTERIOR LIGHT segment is turned on

Step 7 Verify that when the high beam is on, the HIGH BEAM segment is turned on Step 8 End of Test Case

Actual Result:

38

Step 1 The segments are displayed correctly Step 2 The segments are displayed correctly Step 3 The segments are displayed correctly Step 4 The segments are displayed correctly Step 5 The segments are displayed correctly Step 6 The segments are displayed correctly Step 7 The segments are displayed correctly Step 8 End of Test Case

3.9 Exceptions Test CaseRequirements:

The key Status shall control the handling of power of the BCM If Key Status OFF, the ECU shall be capable of turning off the display, while still functioning

in listen mode If Key Status ON, The ECU shall be capable of turning on the display When Key Status OFF, the system shall respond to an Optical Horn request, turning on the

cluster and the display to send the message of the optical Horn When Key Status OFF, the system shall respond to any of the light signals, turning on the

cluster and the display to send the message of the lights When a “Key Off” events occurs, the ECU shall save in the EEPROM the current value of

the odometer, maximum speed raised during the last “Key On” cycle and the value of the last Humidity calculation

If a failure condition is received, this information shall be shown in the screen Stalk position switch shall have the following, Turn Left, Turn Right, High Beam, Low Beam,

Optical Horn If the “Turn left” switch is pressed, shall be not possible to have the “Turn right” switch

press (and vice versa) If the “Optical Horn” switch is pressed, shall be not possible to have the neither High nor

Low beam switches pressed (and vice versa). Network shall use modules such as CANalyzer, CANoe and Canopen

Objective:

Verify the exceptions are accomplished

Prerequisites:


Expected Result:

Step 1 Verify the Key Status controls the power of the BCM

39

Step 2 Set the Key Status to OFF and retest Test Cases 2-8 and verify that only lights test case still operates

Step 3 With Key Status OFF turn on the interior lights and exterior lights Step 4 With Key Status OFF turn on the LEFT STALK light Step 5 With Key Status OFF turn on the Right STALK light Step 6 Turn on the LEFT STALK and the RIGHT STALK several times and make sure both are

not ON at the same time Step 7 With Key Status OFF turn on the HIGH BEAM Step 8 With Key Status OFF turn on the LOW BEAM Step 9 Turn on the HIGH BEAM and the LOW BEAM several times and make sure both are

not ON at the same time Step 10 Verify that the Optical Horn is the same as the HIGH BEAM Step 11 Set the Key Status to ON and verify that all functions return to normal state Step 12 Set a CAN ERROR Flag Step 13 Screen displays CAN ERROR on Position Segment Step 14 Clear CAN ERROR flag Step 15 System returns to normal Step 16 End of Test Case

Actual Result:

Step 1 The BCM reacts to the signal received Step 2 All functions are disabled, except all those concerning lights Step 3 Lights are turned on and the cluster display the segments Step 4 The left stalk is turned on and the cluster display the segment Step 5 The right stalk is turned on and the cluster display the segment Step 6 Both Stalks are never ON at the same time Step 7 The high beam is turned on and the cluster display the segment Step 8 The low beam is turned on and the cluster display the segment Step 9 Both BEAMS are never ON at the same time Step 10 Both share the same segment and performs the same Step 11 All functions perform as expected Step 12 CAN ERROR flag received Step 13 Message displayed Step 14 Flag is cleared Step 15 System in normal again Step 16 End of Test Case

40

3.10 Low Voltage Test CaseRequirements:

System shall identify a low voltage condition from the Voltage input source (battery). System shall display a signal of Low Voltage Operation on the screen when a Low Voltage

condition is detected. The Low Voltage Operation signal shall be the only thing displayed on the screen during

the Low Voltage Operation. System shall store the last value of the Odometer into the EEPROM when the Low Voltage

Condition is detected.

Objective:

Verify the Low Voltage condition turns off everything except the label

Prerequisites:


Expected Result:

Step 1 Send a Low Voltage Status flag Step 2 Verify Screen clears everything off, except for the SYSTEM VOLTAGE label Step 3 Clear the Low Voltage flag Step 4 System Reboots and returns to normal Step 5 With Key Status OFF turn on the Right STALK light Step 6 End of Test Case

Actual Result:

Step 1 Low voltage flag received Step 2 All functions are disabled, except all those concerning lights Step 3 Low Voltage flag is cleared Step 4 The left stalk is turned on and the cluster display the segment Step 5 System reboots and is normal again Step 6 End of Test Case

41

3.11 Low Voltage Test CaseRequirements:

Demo Briefcase

Objective:

Verify all modules work in final form

Prerequisites:

Setup Test Case Disable the demo function and set final code

Expected Result:

Step 1 Connect the briefcase to the power outlet Step 2 Turn on and off all signals in the briefcase and repeat previous test cases Step 3 End of Test Case

Actual Result:

Step 1 Briefcase connected Step 2 All functions are performing as expected Step 3 End of Test Case

42

4 ConclusionsThe implementation of a cluster device was very illustrative in terms of the process cycle for development. It was a massive building step towards the leap made from school to a real job. Not only the teachers provided that experience, both academically and professional, but also created a work environment like that resulted in a very helpful look into the future.

The project also made an impact on how things are planned ahead of time to possible expansions and upgrades. It was a common mistake to create something only by fulfilling some immediate needs, lacking any improvement and if it was needed, the whole project was to be built from scratch. The learning here is invaluable as it result in a work methodology that will be used in any endeavor.

Another very important topic is the requirements. It was fairly common to start something without the realization of the effort, the resources, the tools and the knowledge at disposition. It was established since the beginning to learn by any means possible, emphasizing self-research as a basic tool for any situation. Most commonly than not, the situation presented will prove to be new and no support will be given, forcing the self-research and the use of the very engineering skills this specialization intended to provide.

In terms of the project itself, there were quite a few achievements made. An operative system was successfully ported from one microcontroller to another. The CAN network protocol was implemented successfully providing a channel of communication between nodes. The software architecture basics were applied to the design of the project to make the modules portable and interchangeable. Drivers were developed to interact with the LCD screen. The programming logic itself was improved.

The ECU was put together with the BCM project for a demonstration of the capabilities of both thesis projects. It was fit into a demo briefcase for exhibition and features several switches representing the input signals, and lights as the output signals (those that are not displayed in the LCD screen).

It is an ambitious project for a small team made by students but a very rewarding one. Not only creates experience in the automotive industry, but enables creative thinking, problem solving and feeds the need an engineer has to fully understand the things in life. Also it builds towards some new generations that will update this code, this drivers and the whole project in hope of a better product and hopefully with the same expectations of their future colleagues.

43

5 Appendix

5.1 Diagrams

5.1.1 Key Debouncing task.

Diagram 6_Key Debouncing task diagram.

44

5.1.2 CAN Message Handler task.

Diagram 7_CAN Message Handler task diagram.

5.1.3 CAN Transmit Message task.

Diagram 8_CAN Transmit Message task diagram.

45

5.1.4 Low Voltage task.

Diagram 9_Low Voltage task diagram.

46

5.1.5 Key Status task.

Diagram 10_Key Status task diagram.

47

5.1.6 Screen Update task.

Diagram 11_Screen Update task diagram.

48

5.2 ECU Configuration

5.2.1 PLL System Clockbusclock freq=24 Mhz (2).xtal freq=8Mhz (3).

5.2.2 WatchdogCop Watchdog rate: OSCCLK Cycles to Timeout @8MHz.

COPwatchdog rate= 222

xtal freq=524.28ms

(4).

5.2.3 Timer ModuleThe use of timer is to generate the time base for the scheduler task. The implementation is made configuring a Timer Channel in compare output mode.

Based in the next expression, we can calculate the compare reload value for our desired time.

TimeCompare= 1buscloc k fr eq

∗prescaler∗compar evalue(5).

Assuming that the Prescaler value is 1, and the desired timer freq shall be of 2 kHz -> 500us.

Compar evalue=buscloc k freq

timercompar e freq=24MHz2kHz

=12000(6).

5.2.4 CAN Driver Configuration

5.2.4.1 Clock source and Baud Rate:The clock source for the CAN module selected is the XTAL source or Oscillator.

BaudRate=500kHz (7).MSCAN ¿=CANclk=8MHz (8).

TSEG1=5quantas (9).TSEG2=2quantas (10).

TSEG1+TSEG 2+SYNCHSEG=8quantas (11).

49

Prescaler= CANclk(BaudRate∗timequantas ) =

8MHz(500kHz∗8 )

=2 (12).

50

5.2.5 LCD Driver Configuration

5.2.5.1 LCD Clock and Frame Frequency:The LCD has an Internal Reference Clock connected to the Clock source, in this particular case the reference clock of the DEMO9S12HY64 is of 1 kHz.

IRCCLK=IRC1M = 1kHz (13).

LCDframefreq (Hz )=[ IRCCLK (Hz)Divider ]∗Duty (14).

Table 4_LCD Clock and Frame Frequency.

The important part here is that we have to configure the LCD module according to the table. For this we use:

Divider=4096 (15).

Duty=14

(16).

LCDframefreq (Hz)=61Hz (17).

LCLK prescaler=010b (18).

5.2.5.2 LCD Bias and Modes of OperationThe LCD Module has five modes of operation:

1/1 duty (1 backplane), 1/1 bias (2 voltage levels) 1/2 duty (2 backplanes), 1/2 bias (3 voltage levels) 1/2 duty (2 backplanes), 1/3 bias (4 voltage levels) 1/3 duty (3 backplanes), 1/3 bias (4 voltage levels) 1/4 duty (4 backplanes), 1/3 bias (4 voltage levels)

51

Table 5_LCD Duty and Bias

As the project uses all segments, it means uses all Backplanes and the Duty is set by the frame frequency, the BIAS is also configured according to table Table 5_LCD Duty and Bias

5.2.5.3 LCD RAM:For a segment on the LCD to be displayed, data must be written to the LCD RAM. The 160 bits in the LCD RAM correspond to the 160 segments that are driven by the front plane and backplane drivers. Writing a 1 to a given location will result in the corresponding display segment being driven with a differential RMS voltage necessary to turn the segment ON when the LCDEN bit is set and the corresponding FP [39:0] EN bit is set. Writing a 0 to a given location will result in the corresponding display segment being driven with a differential RMS voltage necessary to turn the segment OFF.

5.3 Message matrix

Table 6_Message matrix table

52

6 References[1]. V-cycle Development Process Software Engineering, Marco Bozzano,

http://disi.unitn.it/~tomasi/sweng/vcycle.pdf.[2]. OPERATING SYSTEMS Scheduling, Jerry Breecher

http://web.cs.wpi.edu/~cs3013/c07/lectures/Section05-Scheduling.pdf.[3]. CAN Specification Version 2.0, BOSCH, http://esd.cs.ucr.edu/webres/can20.pdf.[4]. Layered Software Architecture, AUTOSAR,

http://www.autosar.org/download/R3.0/AUTOSAR_LayeredSoftwareArchitecture.pdf[5]. Software Testing Tutorial,

http://actoolkit.unprme.org/wp-content/resourcepdf/software_testing.pdf[6]. Auto-tuning Performance on Multicore Computers, Samuel Webb Williams, Electrical Engineering

and Computer Sciences University of California at Berkeley , http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-164.pdf

53

http://actoolkit.unprme.org/wp-content/resourcepdf/software_testing.pdf

http://www.autosar.org/download/R3.0/AUTOSAR_LayeredSoftwareArchitecture.pdf

http://esd.cs.ucr.edu/webres/can20.pdf

http://web.cs.wpi.edu/~cs3013/c07/lectures/Section05-Scheduling.pdf

http://disi.unitn.it/~tomasi/sweng/vcycle.pdf

Documents

04_Tesis