Designing a Vehicle Instrument Panel Cluster—A Case Study

	ABOUT THE AUTHOR Aneesh Mathai is a Member of Technical Staff at CG-Smith Software, Bangalore. He has worked on Real Time Embedded Systems and Software for more than 5 years. Aneesh received his Bachelor of Technology in Electronics Engineering from Cochin University of Science and Technology. He is also a Member of IEEE.

In modern vehicles, software-controlled electronics plays a major role in the functioning of the vehicle's subsystems. In a medium-sophistication vehicle, there will be 8 to 10 intelligent electronic modules performing functions such as engine control, transmission, brakes, steering, navigation, HVAC, safety, security, audio, driver information, and others. Though each of them works on its own, the modules will be connected using some in-vehicle network. Communication protocols such as SAE J1850, CAN, and KW2000 are commonly used for automobile inter-module communication.

The Instrument Panel Cluster (IPC), or Vehicle Dashboard, is one of the few devices with which the vehicle communicates to the driver. Devices such as a driver information center and heads-up display are considered subsystems or add-on devices to the IPC. Even though, from technology and complexity perspectives, the IPC is simpler than other modules, it is important to the driver, since it is one of the few modules the driver sees.

The IPC module takes signals from various sensors and communicates with almost all the other modules in the vehicle to get relevant information and status about the vehicle. The IPC processes data and provides information in an appropriate form to the driver.

• Analog speedometer display
• Analog tachometer display
• Analog fuel display
• Analog engine coolant temperature display
• LCD single-line season/trip odometer
• Nine discrete LED or bi-pin lamp telltales
• Driver information center (DIC)—18*2 character dot-matrix display
• Mode and reset switches to control the DIC and trip stem for odometer.

This list shows a typical requirement specification of an instrument cluster for a medium-sophistication vehicle such as a car or truck. Advanced clusters will have a higher number of gauges, high-resolution displays, compass, and other display features. These clusters may even integrate features such as security, vehicle immobilization, and so on, which are normally handled by other modules, in the vehicle.

You cannot design the cluster system from the previous specification alone. You need information on the types of inputs to the IPC, which needs to be processed. All the displayed data may not be directly sensed by the IPC. Other modules will sense and process some of the data and will then send this data to the IPC through an in-vehicle communication protocol.

You can divide inputs to the instrument cluster into four broad types, with examples of each shown:

• Analog inputs (ignition voltage and coolant temperature)
• Discrete inputs (switches and washer fluid status)
• Digital pulses (Vehicle speed sensor output)
• Serial data (Information from other modules such as the fuel used, telltale status, and warning data).

From the specifications and requirements described earlier in this article, you can develop a basic block diagram (Figure 1). First, we can summarize our system as follows:

1. Four gauges
2. Nine LED telltales
3. Seven-segment LCD display (six digit)
4. Dot-matrix display (18*2 character)
5. Serial-communication module
6. Analog/discrete/pulse inputs
7. A microcontroller to process data and control the devices.

After obtaining the basic block diagram, you now must select the devices and components that the system will contain. The considerations for selection include performance, price, availability, compatibility with other devices, and other factors.

There are many methods to electronically move gauge pointers. A simple and straightforward method is by using stepper motors to control the gauges. To interface a microcontroller to the stepper motor, you can use stepper drivers, of which many types are available. For example, Switec provides an M-S quad driver that can control four stepper motors at a time, which is optimal for our requirement. The Switec driver provides a micro-step of 1/12th of a degree for each edge of the pulse train coming from the processor. Independent direction control and movement is possible for individual stepper motors. We can also use buffers to drive the stepper motor by using high-frequency pulse-width-modulated (PWM) signals generated directly from the microcontroller, but this requires more dedicated microcontroller I/O pins.

We need to drive nine LEDs. It is a waste of port pins if we try to drive the LEDs directly from the microcontroller. Furthermore, the microcontroller may not have the required current capacity. Instead, we can use an LED driver for the same purpose. LED drivers that connect directly to the microcontroller through SPI/I²C are available.

The season odometer is usually six digits, so we need a six-digit seven-segment LCD display. Other symbols such as "Km", "MI", and "TRIP" may also need to be displayed, thus requiring a customized LCD display.

The DIC requirement is a two-line, 18-character display. You first need to choose between a VF tube and LCD displays. Both types are common in DICs. In our case, we will select an LCD display with back lighting. The next step is to choose the display driver. This display should be accessible by the processor using SPI/I²C. Depending on the type and number of characters to be displayed, the display driver should have enough character-generator ROM. Features such as a reverse video option should be taken under consideration while choosing the driver.

We first need to identify the type of in-vehicle communication the vehicle will use. The latest microcontrollers have in-built communication modules, supporting protocols such as SAE J1850, CAN, and KW2000. Another alternative is to have an external chip that connects directly to the bus accessed by the microcontroller using SPI/I²C.

The microcontroller selection is one of the most critical parts of the system design. You have many considerations to take into account, both software and hardware, in selecting the ideal microcontroller. Following are the minimum requirements for our processor.

• 30 I/O lines that are pin addressable
• Analog-to-digital module with five A/D channels/pins
• An SPI/I²C module capable of driving five devices
• External/Internal Interrupt capability
• Two to four general-purpose timers.

Other than these functions, you may also consider other built-in functions for the microcontroller, such as a built-in vehicle communication module, stepper driver, or LCD driver. On average, the complete processor software will occupy 70 to 90 Kbytes of ROM, 3 to 4 Kbytes of RAM, and 100 to 200 bytes of EEPROM. The microcontroller you select must have enough on-chip memory. You use the EEPROM for data backup, so it is best to keep it outside the processor. EEPROM chips with 256 bytes, accessible through SPI/I²C, are available.

You next need to choose the processor type and clock frequency. The system can use either a 16- or 8-bit processor, depending on the complexity of the processing. We may have a tradeoff between bits and clock frequency. Optimum clock frequency to use is around 4 MHz for a 16-bit processor or 8 MHz for an 8-bit device.

After selecting the required components for the IPC, you next need to design the electrical circuit. Before going to that step, we need a detailed block diagram for better clarity.

Figure 2 shows the configuration of the microcontroller pins. Separate pins are used to enable the peripherals. The built-in ADC senses all the analog inputs. Separate port pins are used to give pulses to the corresponding stepper motors. Write software such that with one direction pin, you can control the direction of all the stepper motors independently. Vehicle speed pulse train is given to the Capture interrupt/Timer pin so that no pulses are missed. A wakeup interrupt pin is provided for waking up the controller from sleep mode. Two PWM pins are provided to control the backlighting of the LCD odometer and DIC.

Figure 2:  Microcontroller pinout

Figure 3 shows the block diagram of stepper motor section. A quad stepper driver is used to control the stepper motors. Pulse train input for each stepper comes directly from the microcontroller. A single direction pin is used to control all the stepper motors. Software will take care of independently controlling the motors.

Figure 3:  Stepper motor controller

Through SPI, we will transfer data between the microcontroller and devices such as external EEPROM, LCD driver, LED driver, DIC driver, and communication module (Figure 4). The communication module and EEPROM have two-way communications. The other devices are also connected as bi-directional units since, at times, the microcontroller needs to read the status of the control registers.

The signal conditioning section (Figure 5) deals with the conversion of various signals to signals compatible with the microcontroller. Ignition and battery voltages are scaled down to a 5V range. A 2.5V reference voltage is generated from regulated 5V DC. The regulator supplies power for all the peripheral ICs and circuits. The microcontroller can switch off the regulator using PWR_EN. The processor will go into sleep mode when the ignition switch is off and there is no activity on the communication bus. The processor is awakened by the WAKE_UP signal, generated by OR-ing Bus status, ignition switch and trip switch.

Figure 5:  IPC signal conditioning

After completing the detailed block diagram, we can design the electrical circuit. Details of this task are beyond the scope of this article.

In a real-time embedded system, software plays the most important role in how the system functions. Now you have a system, which you need to make intelligent by developing the appropriate software. There are many parameters you need to consider before writing the code, such as selecting the operating system, device drivers, and communication-handling protocols. It is good practice to write the code after preparing the design documents. Design documentation consists of a control flow diagram, data flow diagram, data dictionary, and pseudo code/flow chart.

Since the cluster program is straightforward and does not require very complex priority handling, we do not need a commercial RTOS. We can design our own non-preemptive operating system. The basic time rate is dependent on the time-critical specifications. In our case, this rate is around 10 ms. We can have tasks occurring at:

10 ms
20 ms
200 ms
500 ms
1 second

You can design the operating system such that only two task combinations are occurring in one time slot. Table 1 shows a typical arrangement of the tasks in the RTOS (placing of a one-second task is not shown in this table. Assume the one-second task is in the 94th time slot).

Table 1:  Typical arrangement of the tasks in the RTOS

From the Table 1 arrangement we will get task combinations such as:

Task Combinations
10 ms
10 ms + 20 ms
10 ms + 200 ms
10 ms + 500 ms
10 ms + 1 second

After deciding on the structure of the RTOS, we have to allocate our functions in the corresponding tasks. Care should be taken not to overflow the time slot. The 10 ms task should be made the minimum execution time so that there is enough room for other task combinations.

Writing the code in assembly code will make it compact and faster, but reduces code maintainability. Many programming languages are available for Embedded software development such as C, Modula 2, and ADA. It is a good idea to use C as the programming language because of the language's easy portability, reuse, and popularity.

Device-driver development is another important task in software design. This is very specific to the processor and types of devices you use. We can reuse the device driver modules if they are available in similar projects with the same processor. You must develop the modules to handle an SPI interface with different devices, analog-to-digital conversion, stepper-motor control, and I/O handling.

The communication in a real-time system is usually mapped with an Open System Interconnection (OSI) Seven Layer model for communication networks.

Following are the seven OSI layers:

1. Application
2. Presentation
3. Session
4. Transport
5. Network
6. Data Link
7. Physical.

While considering in-vehicle communication protocols like J1850 or CAN, we may not exactly map to OSI layers. The generic communication-handler modules will usually be available. We have to make these modules compatible with the cluster software. Following is a discussion of the software layers normally used in vehicle communications. While designing the software, it is good practice to place each layer in a separate module.

• Device-Driver Layer—This software layer provides the control necessary to manage data flow in and out of the protocol device. The primary purpose of this layer is to convert service requests to device-specific commands, and to convert device-specific status information to a device-independent format. The upper layers utilize this layer to move byte streams to and from the protocol device without needing to know what specific protocol device implementation is present. In our case, we are using SPI to communicate with the protocol device. We will use a separate device driver for SPI communication, and will use the same device-driver functions for communicating with the protocol device.
  
  
• Message Loader/Unloader Layer—This software layer is used to manage one specific message which is either to be transmitted on or received from the link. From the transmit perspective, this layer is used to construct a valid message and pass the resulting byte sequence to the device driver, one byte at a time. From the receive perspective, this layer is responsible for constructing and buffering valid messages from the sequence of bytes passed to the layer from the device driver.
  
  
• Message-Manager Layer—This software layer is used to manage the collection of messages utilized by the device. From the transmit perspective, this layer is used to determine which message is next to be transmitted on the link, and to request from the message loader/unloader that the message be transmitted. From the receive perspective, this layer is responsible for processing received messages passed to this layer from the message loader/unloader.
  
  
• Application Layer—This layer consists of software that generates the message transmission requests and utilizes received message transmissions. This layer is the ultimate source and destination of all message data. In our case, fuel messages, warning messages, and telltale messages, among others, are received through in-vehicle communication. The application layer will pass the data to the corresponding application modules for processing and taking actions dependent on the received data.

The final major task in software development is writing the application code. First we will split the complete application into different features. This is the phase for which we need to gather exact customer requirements, including all the minute details. After the necessary clarifications, we will finally go to the system's features. We will allocate separate modules for each feature. Some features can have more than one module, depending on how we can maintain and reuse that module. Modules will have global functions, which will be called directly or indirectly in the appropriate time-slot of the RTOS. The following features/modules will be appropriate for our application.

• Odometer Value Computation
  Computes and updates the odometer by taking the pulse input from the vehicle speed sensor.
  
  
• Odometer Display
  Converts odometer data to a displayable format.
  
  
• Telltales Display
  Turns on the LEDs depending on the various status of the vehicle.
  
  
• Gauges
  Process various parameters and convert them into a format that can drive the stepper motors.
  
  
• Stepper-Motor Interface
  Drives the stepper motor by generating pulses to the stepper driver.
  
  
• Power Mode
  Determines the power mode of the cluster by looking into the ignition switch status and power-mode message from other vehicle modules.
  
  
• Driver-Information-Center Functions
  Processes various driver-information functions, including trip distance, average speed, fuel economy, fuel used, range distance, and outside air temperature, and converts the data into a displayable format. Many calculations and algorithms might be involved in this operation. It is good practice to have separate modules for each of these functions.
  
  
• Serial Peripheral Interface
  Handles the SPI interface between the microcontroller and peripherals.
  
  
• Dot-Matrix LCD Driver
  Sends various DIC parameters to the LCD display through SPI.
  
  
• Seven-Segment LCD Driver
  Sends odometer data to the seven-segment LCD display through SPI.
  
  
• LED Display Driver
  Telltale displays are illuminated by setting the corresponding bits and sending the bits to the LED driver through SPI.
  
  
• Dimming
  Backlighting of LCD displays, gauge backlighting, and LED intensity are controlled by the PWM output from the microcontroller.
  
  
• Input/Output Processing
  Reads various input ports and periodically sets the output ports.
  
  
• ADC Handling
  Periodically converts all the ADC-channel data and stores the result.
  
  
• External EEPROM Handling
  The external EEPROM is read and written through SPI. Putting data in a buffer and sending it bit-by-bit serially needs to be handled properly since an EEPROM write may take 3 to 10 ms. You can use separate modules for the EEPROM driver and EEPROM queue handling.