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.
New Software Expertise
Die-hard embedded engineers from the analog cluster world need to make several adjustments when moving to the software environment of a digital cluster. To begin with, the move to a commercial RTOS requires a whole new toolchain. Also, to migrate to 32-bit C, engineers must eliminate any bad habits that have crept into the code base, such as performing direct memory peeks or assuming that “int” is a particular size. Lint tools can help simplify the move, though getting code to compile lint-free can be time consuming. Often, 8- or 16-bit CPUs require sized pointers a la everyone’s favorite 8086 legacy of segment registers. The 32-bit world doesn’t require these sized pointers, and engineers need to typecast or #define them away.
Other challenges arise from the engineer’s mindset, rather than from the code itself. Unlike the static memory management used in an analog cluster (no mallocs or frees, thank you), the digital world is bigger and more complex. Many graphics libraries and widget frameworks rely on active memory management. Engineers must accept that they cannot preallocate every buffer as static; rather, they must allow for a dynamic heap. As a result, the development team must perform careful testing to catch all heap leaks before deployment. The OS should provide tools to help here. For instance, specialized analysis tools in the Eclipse-based QNX Momentics IDE allow engineers to detect hard-to-find dynamic memory leaks.
Another mindset adjustment concerns threads. In most roll-your-own solutions, task “scheduling” consists of nothing more than the task loop sequentially calling each routine. Preemption cannot occur because tasks share a single set of registers and stack. Under an RTOS, preemption definitely occurs, and engineers must use synchronization locks to protect practices that may once have been safe, such as reading and writing shared memory structures. This can be a hard habit to acquire for an engineer who is used to thinking of each variable as unmutable, and any forgotten semaphore locks will likely cause frustratingly irreproducible bugs. To avoid this problem, engineers can bury all accesses to shared variables within an API; that way, they need to get the locking code right only once.
If the engineering staff is willing to brave a move up to C++, even the API can look as natural as a normal variable manipulation. The conversion to C++ doesn’t have to include templates, operator overloading, or any of the more esoteric features of the language. Rather, the engineering team can create easy-to-use classes that act like normal variables, but that contain (and hide) all of the appropriate locking and unlocking.
In an analog cluster project, the code is relatively small and can be managed by one or a handful of resident engineers. Consequently, the team will probably lack integration skills. Compare this to a digital cluster project, which requires an RTOS, a board support package, device drivers, graphics libraries, graphical resources, and other components. The team must link or bundle all of these separate pieces to make a final product. To perform this integration repeatably and consistently, the team must implement a reliable build process, use a reliable configuration management methodology, know where to get each component and who to get it from, know what may or may not break when introducing patches or revision levels of each component, and control the team updates in lockstep. Thus, it makes sense to assign one person the role of integration lead and have him orchestrate all these details.
If the digital cluster connects to the head unit or uses Adobe Flash, networking, or other advanced technology, the staff may also need to learn socket programming, USB, XML, and other techniques. Plenty of online resources and documentation for these topics exist; though, in some cases, borrowing or hiring experts is the best solution.
Safety Critical Software
The software for a digital instrument cluster is safety critical. Nonetheless, some software components may need to change frequently if the automaker is to reuse the same basic design across multiple vehicles. Those two characteristics don’t coexist easily. The best defense: use runtime software components that have a good track record in safety industries. Also, the development team must choose tools that help find bugs at design time or test time, not after deployment. As an example, the QNX Neutrino RTOS is well suited to this task, having been field tested in many life-critical applications. It also uses a memory-protected microkernel architecture that can uncover memory errors and other system problems more quickly than some other OS designs.
Also, engineers should design the system to detect and correct problems that may occur during runtime. While this approach doesn’t replace the hard work required to ferret out problems during product testing, it can prevent a vehicle recall if a minor glitch escapes the bug-fixing phase. A high-availability software service like the QNX critical process monitor can catch faults and log them, restart the faulted process, or take other scripted actions.
Graphics API
To create an attractive and realistic-looking gauge, engineers could simply use pixel and line drawing, but that would be exceptionally painful. The reasonable approach is to use a standardized graphical API, like OpenGL ES or OpenVG, that provides a range of tools to create 3-D lighting and shading effects (see Figure 2).
Note, however, that these APIs assume some knowledge of the graphical rendering pipeline and often require matrix math, as well as the creation of complex vectors to define rendered objects. Often, engineers can get started by leveraging a pre-existing source code example, but they still must understand how the example works to modify it for the application at hand.
Using sophisticated graphical libraries also lets the software engineer take advantage of hardware-accelerated drawing without having to build such functionality directly. Any good library will automatically use the acceleration features present in the graphics chip.
The development team should choose a graphics library and chip combination that supports shading and lighting effects, anti aliasing, alpha blending, and texture mapping. They should also choose a display that has at least 18 to 24 bits per pixel; this will ensure smooth, rather than jagged, gradients.
Design Toolkit
Depending on the design of the digital instrument cluster, engineers may use widgets that have already been created, such as icons (indicators), rolling number displays (odometer, trip meter), and menus (English/Metric, trip A/B, status mode switch). Although engineers can create all widgets in-house, a design toolkit from a company like Altia, Adobe, or Electrobit that provides pre-constructed and pre-debugged widgets can be a big time saver.
Adobe Flash can be a helpful shortcut. Flash provides an environment that allows graphical artists and industrial designers to develop a product concept and test it on a PC. Running the compiled Flash executable on the cluster’s RTOS eliminates the need to translate the graphics into another environment, such as C or Java.
Flexible Design Choices Rule the Day
To sum up, compared to an analog cluster, a digital instrument cluster provides complete freedom to alter the display on the fly. For instance, a digital cluster can:
Inform the driver of constantly changing road conditions by showing visible speed limits (see Figure 3), obvious road ice indications, or surrounding vehicles.Embedded engineers from the analog cluster world will need to make adjustments when moving to the software environment of a digital cluster, but the move should be well worth it.
About the Author Andy Gryc has been a software developer and designer for more than 20 years. He has worked as the lead embedded software architect for GM OnStar, designed and implemented a speech recognition engine for a speech technology company, and served as a member of the Hewlett-Packard team that created the software for palmtops and the BIOS for the Omnibook notebooks. He currently works as an automotive product marketing manager at QNX. His email is [email protected].