Traditional instrument clusters consist of plastic housings that contain indicator lights and mechanical gauges driven by stepper motors. A digital instrument cluster replaces the mechanical gauges with virtual ones drawn on an LCD display driven by a microprocessor and graphics controller.

Digital instrument clusters were once available in only high-end luxury models, but they are beginning to trickle down into mid- and low-cost vehicles. Many factors are driving this migration:

• Automakers can deploy the exact same hardware in multiple vehicle lines simply by reskinning the graphics; fixed-function gauges, by comparison, must be retooled.

• Cars with complex hybrid or electric drive trains can have multiple drive modes; a digital cluster can dynamically change what information is displayed as the car shifts from one mode to another.

• Digital clusters can help reduce driver distraction and assist driver performance by displaying only the information that the driver currently requires.

• Attractive graphics can enhance the appeal of the vehicle brand more easily than static gauges.

• Compared to a static mechanical display, a digital display can pack in more functionality without increasing the fixed per-unit cost.

• The costs of adequately performing displays and CPUs are dropping.

Displays for a digital instrument cluster must address several requirements. Because the cluster must fit in the space between the steering wheel and windshield, the display must be as wide as possible, yet short. Currently, most designs use displays 1280 pixels wide by 480 tall. The display must also be visible in sunlight: it needs to provide bright, high-contrast graphics and use a matte, non-reflective finish. Placing the display deep in the dashboard well can also help prevent sunlight from washing out the display.

The display in a digital instrument cluster must often draw gauge needles diagonally. To render them smoothly, the display needs a color depth of at least 16 bits per pixel. In some cases, the display may need to support up to 24 bits per pixel, either to achieve the desired smoothness or to render graduated blends in the background image. Drawing attractive gauges also requires anti-aliasing, which is typically handled by the graphics controller.

CPU requirements for a digital instrument cluster depend on the sophistication of the human machine interface (HMI) and on whether the system uses a graphics processing unit (GPU). Several automotive processors are well suited for this usage, including Freescale's 5121e and i.MX35, and Fujitsu's MB86R01 (aka "Jade"). Fujitsu's processors also have specialized features for instrument cluster designs, such as graphics-validation units for safety monitoring, and sprites (dedicated graphical icon display units) for indicator lights.

The software for a digital instrument cluster is much more sophisticated than that of an analog gauge. With a simple analog instrument cluster, the processor needs to get measurements off of the vehicle bus (CAN or MOST), directly measure some values through A/D channels, drive stepper motors and indicator lamps, and possibly control a LED/LCD driver information display. A digital cluster replaces the small, single-line LED with a full graphics display, which requires correspondingly more horsepower and software complexity. Using a standard graphical framework, such as OpenGL ES for 3D or OpenVG for 2D isn't mandatory, but can simplify design choices for graphical toolkits. In most cases, graphical toolkits, such as those from Adobe, Altia, Electrobit, or Tilcon, are ported to talk to a standardized API; having an API such as OpenGL ES or OpenVG allows developers to use these toolkits without having to port the toolkit software to a non-standard API.

OpenGL ES is a well-defined subset of OpenGL, the most widely used 3D graphics API in the computer industry. As a result, automotive development teams that use OpenGL ES can tap into a large pool of graphics programming expertise and source code, not to mention a wealth of documentation, both online and in print. Despite its small footprint, the API supports advanced features such as alpha blending, Gouraud shading, and texture mapping, along with modeling, transforms, lighting, and numerous other techniques. As a vendor-neutral, multi-platform API, OpenGL ES allows developers to reuse 3D code in new projects or across an entire product family. An OpenGL ES application can, without code modifications, run on multiple graphics chips and operating systems; it can also migrate from a low-cost system that uses software rendering to a more expensive system that uses a 3D acceleration chip to improve frame rate or resolution.

Having the capability to merge content from multiple sources can be helpful as well. For example, the system designer may decide to use a full-featured graphical environment like Adobe Flash Lite for the background image "skins," but use a simple application based on OpenGL ES for the needle display. The system designer will need to choose software and hardware that can combine the two layers, either through hardware layering features in the graphics controller or through a software compositing system, such as OpenKode.

Figure 1. An example software architecture for a digital instrument cluster. Two applications (one for the gauge backgrounds, one for the needles) combine their output through the graphics driver, using hardware layers. Each application gets the data it requires from a digital acquisition manager that gathers the required information from incoming CAN messages. The two "graphics driver" blocks are actually the same module, separated only for diagram clarity.

Correct operation of the instrument cluster has safety implications: if the gauges stop reading properly, the driver may break laws, damage the vehicle, or even endanger the occupants. A reliable real-time operating system (RTOS) is a must. Integrating high availability monitoring processes, which watch for software component failures and take corrective actions such as restarting a failed component, can also help ensure fail-safe operation. The RTOS and cluster application software must also boot quickly, bringing up the gauge display within one or two seconds of ignition crank.

. Figure 2. A digital instrument cluster can dynamically display information, such as current speed limit, in an intuitive way.

The characteristics described so far create a digital instrument cluster that works at least as well as a standard analog cluster. However, the flexibility gained by a completely dot-addressable display offers automotive OEMs and Tier 1 suppliers much more room to innovate. For instance, a digital cluster could:

• dynamically display road conditions, such as speed limits, road ice, or surrounding vehicles

• allow users to customize the display according to their preferences (selectable color schemes or wall papers)

• reconfigure for day/night or English/Metric

• deemphasize unnecessary information to reduce driver distraction, such as dimming gauges (e.g. oil pressure, battery voltage) that display values in a normal range

• alter the display according to the car mode: emphasize RPMs in performance mode, show energy consumption in fuel-saving mode, etc.

• incorporate current features such as navigation, back-up camera, or parking assist with advanced Internet connected applications such as weather, cheapest nearby gas station, song artist information, etc.

Some of these features are in current production vehicles, while others are still on the drawing board. An increasing amount of digital content is making its way into the car — everything from satellite traffic content to music from personal media devices. Digital instrument clusters, with their ability to display the right information at the right time, can help drivers enjoy the benefits of this content without being overwhelmed (and thereby distracted) by it. This flexibility, combined with the potential to reduce costs and create market differentiation, explains why many automakers and Tier 1 suppliers are now developing digital instrument clusters for their future vehicles.

Figure 3 Adding weather and turn-by-turn components to the cluster. .

Andy Gryc works in Automotive product m