Digital instrument clusters are poised to supersede analog clusters in next-generation vehicles. This may seem surprising at first, since digital clusters require higher-end CPUs and much more software than their analog counterparts, not to mention large LCD panels. Why, then, are automakers adopting them? Here are some of the reasons:

• Reusable: With a digital cluster, automakers can deploy the exact same hardware across multiple vehicle lines simply by reskinning the graphics.
  
  
• Dynamic: A digital cluster can dynamically change what information is displayed as the car shifts from one drive mode to another: off-road, performance, highway, and so on.
  
  
• Simple: Digital clusters can help reduce driver distraction by displaying only the information that the driver currently requires.
  
  
• Scalable: Automakers can pack more functionality into a digital cluster by changing the software only; they don’t have to incur the cost of machining or adding new physical components.
  
  
• Attractive: A digital instrument cluster can enhance the appeal of a vehicle with eye-catching graphics and features.

Analog Clusters Have Served Us Well

To appreciate both the benefits and the challenges of digital instrument clusters, we first need to examine what they have evolved from: analog clusters. A typical analog cluster includes the following components:

• Stepper motors: Long gone are the days when a speedometer cable reached from the engine to directly transmit the speed; modern gauges use a stepper motor to control the needles, one for each needle. The CPU sends pulses to the motors to set the needles appropriately.
  
  
• Processor (CPU): An analog cluster typically uses an 8- or 16-bit CPU that has onboard analog-to-digital converters, general-purpose I/O (GPIO) pins, and other peripherals. Because the CPU needs only enough horsepower to read the CAN bus for speedometer updates and to drive the stepper motors, most designs use a lower-cost CPU.
  
  
• Analog-to-digital converters (ADCs): These measure fuel level, battery charge, and other information by directly sampling the voltage level. They can also detect failure conditions (for instance, voltage drop on a backup battery) and detect when a single wire carries multiple signals (for instance, a resistive ladder on a steering wheel button). The ADCs may reside on the system-on-chip or on a discrete chip.
  
  
• LED/LCD drivers: An analog cluster has a large number of indicator lights, including seat belt, turn signals, low fuel, low battery, low oil pressure, and service engine. The CPU or another module may drive some of these indicators directly, but in most cases, the CPU intercepts a CAN message and sends a signal through a GPIO to turn the indicator on or off. Some clusters use a segment display for the speedometer or the odometer/trip meter.
  
  
• CAN bus interface: The cluster gets most of the information that it displays from the CAN bus. To minimize costs, most designs use a CPU that has the CAN interface built in.

The software behind an analog cluster is fairly simple. It doesn’t need an operating system (OS), since all tasks can execute within a fixed duration in a small, tight loop. To develop the software, engineers need traditional embedded skills: setting and reading bits for GPIOs, debouncing switches, reading ADCs, receiving and sending CAN messages, and performing other direct-to-hardware tasks.

In any cluster, the software is safety critical. A malfunctioning cluster can’t directly kill or injure, but it can give false indications that may lead to an accident, a speeding ticket, or a stranded driver. As a result, the development team rarely modifies the software once it has been written and validated.

Digital Clusters Are the Future

Moving to a digital instrument cluster introduces a number of significant changes, especially for a development team with experience in analog clusters. To begin with, the cluster needs a large LCD display — often 1280 x 480 pixels. An 8- or 16-bit CPU cannot move that many pixels, so the cluster needs a 32-bit CPU with clock rate of at least 200 MHz. The cluster also needs a graphics controller to drive the display. This controller may or may not reside on the CPU. The cluster still needs a CAN interface and one or more ADCs to get information to feed the virtual gauges; but without physical needles, it no longer needs stepper motors. Since the screen can display any indicators, there’s no need for segment displays or an independent LED or LCD driver.

The biggest changes occur on the software side. Due to the software required to render the digital cluster’s graphics, an RTOS is a necessity. In addition, the level of software expertise needed extends beyond the traditional embedded skill set.

RTOS Required

When creating a digital instrument cluster, design teams usually find that an off-the-shelf RTOS is significantly easier to use than a “roll your own” OS. To draw gauges, indicators, text announcements, and other components, software engineers need to call into a graphics library. Creating a homegrown graphics framework is neither practical nor cost efficient. The design team may rely on a widget toolkit to simplify the implementation of a rolling odometer, menu system, or other specialized controls. Most standardized graphics libraries take advantage of low level-OS primitives to load the graphics library as a shared object, access the hardware frame buffer, handle interrupts, perform dynamic memory allocation, access the timer, and perform thread synchronization.

Few homegrown OSs support such features. More importantly, if a team wants to modify its homegrown OS to take advantage of a third-party graphics or widget framework, the framework vendor must provide complete source code, which does not often happen.

A digital cluster also needs an RTOS to ensure deterministic response. In an analog gauge, a simple task loop works well because each task executes within a short, fixed time interval. But in a digital instrument cluster, the timing required to draw an object may depend on the angle that the needle is drawn, on graphical pipeline constraints, or on what else was drawn immediately before the object. The cluster may need to sample a particular GPIO or ADC at a precise frequency, which could be altered by the non-static draw timing.

To combine nondeterministic tasks with those that need real-time response, the engineer has but one choice: create separate threads for each task and schedule those threads on a priority basis. A home-grown OS almost never supports this level of sophistication. By creating a high-priority thread for the code that must execute at a regular frequency and lower-priority threads for the graphics rendering, engineers can create a system that satisfies functional requirements while remaining responsive to the user.

In a cluster application, fast boot-up times are an absolute must. The user won’t wait several seconds for a speedometer to appear or for a rear-view video feed to back out of their driveway --a second or two is the longest tolerable delay. Consequently, the RTOS must boot very quickly. The QNX Neutrino RTOS, for example, provides several technologies for booting within strict time constraints, such as allowing engineers to completely reorder device startup and executing vehicle bus drivers in parallel with the OS booting process. A sample software architecture for a digital instrument cluster is shown in Figure 1.