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).

Figure 2. 3-D graphics can be used to create an attractive cluster display.

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.

  Figure 3. This digital instrument cluster is highlighting the current speed limit of 100 km/h.

• Allow the user to customize the display by altering the color, wallpaper, or gauge layout.
• Reduce driver distraction by dimming, removing, or deemphasizing gauges that the driver doesn’t currently need (see Figure 4).

Figure 4. This digital instrument cluster is deemphasizing unneeded information, such as RPMs.

• Provide a different display for each mode of operation: performance, off-road, fuel-saving, and so on.
• Integrate turn-by-turn navigation (see Figure 5), backup camera, weather, nearest gas stations, album art, and other advanced features.

Figure 5. This digital instrument cluster incorporates album art (lower right) and turn-by-turn navigation (lower left).

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.