The instrument cluster is experiencing a radical reinvention. Screens are taking over the cluster because the cost of both the screens and the silicon to drive displays is going down. In some cases, the cluster is a combination of physical gauges and a screen; in others, all cluster information is presented on a large thin-film transistor (TFT) displays. In either implementation, the cluster is prime, driver-critical real estate, making its deployment no typical human-machine interface (HMI) challenge. All features and functionality must be easy to understand. Additionally, the entire embedded cluster system must be extremely safety-focused, performant, and fault tolerant.

Lessons learned from how to build smaller driver information displays need to be scaled up dramatically. Let’s look at four of the biggest areas of opportunity: heterogeneous displays, advanced silicon, simplified certification, and native C development.

In the automotive market, not all screen elements are created equal. For example, it’s nice for you to know that your washer fluid is low. A status element in the vehicle cluster provides that information quickly and easily. However, it’s more important to know that you’re exceeding the speed limit. Washer fluid status isn’t safety critical. Your speed is.

With this in mind, most automakers strive for 60 frames per second (FPS) frame rates or better for speedometer and tachometer display elements to create a smooth appearance and so that information updates in real time. Other graphics – such as fuel and vehicle status – can typically run at 30 FPS or slower. Having separate frame rates for different elements is a departure from traditional graphics code, as simple approaches just draw to the screen with each screen refresh updating all elements.

A smarter tactic requires a re-architecting of the code to separate how graphics are handled. This can be done by creating separate code loops that update different elements at different frequencies, and assisted using hardware layers to decouple what gets redrawn (more about the benefits of hardware layers next). It’s very important that execution of this approach does not adversely impact performance, since achieving 60 FPS on low-end hardware can be a challenge all by itself.

Use or lose

Silicon vendors are innovating with automotive industry applications in mind, releasing new embedded processors that allow cluster development teams to get more performance from less expensive chips. It’s up to cluster development teams to leverage the advanced features of their hardware so that they can wring the most out of their selected processor. The design of the hardware can offer significant performance gain while keeping bill of materials (BOM) costs low.

For example, some hardware offers dual pipelines for getting graphics to screen. Using both pipelines can greatly accelerate performance for graphic-intense screens because precious CPU cycles are spent building render lists for the GPUs to execute in parallel. Moreover, one of those pipelines is often tailored to the hardware platform – like RGL on Renesas parts or IRIS on parts from Cypress or NXP. These graphic libraries are custom-architected and honed by Altia and silicon vendor partners to get the best performance from the hardware.

An underutilized but quite powerful platform feature is hardware layers. Almost every modern cluster user interface consists of graphics that are stacked on top of one another. This means that when an area of the screen is being redrawn, the hardware is working to draw each of these graphic pieces and determine which parts should be combined and pushed out to the screen. Layers do all of this work for you, relieving the CPU of this unnecessary burden. You can even use layers to effect CPU-free, simple animations. Common animations like hiding and showing or moving objects across the screen are easily accomplished by leveraging hardware layers.

Furthermore, layers – when used correctly – can dramatically decrease ROM and RAM requirements. When you think about an instrument cluster, the background image would typically be one layer, needles that must be updated frequently could be another layer, and safety-critical telltales could be a third layer. For the latter two cases, the graphic detail can be minimal. The image quality of the background likely needs to be very high, which drives up the memory needed. Being able to separate these image quality requirements means that you can save valuable memory. While in this case we only call out low and high quality elements, there are many shades in between, giving the developer the fidelity required with the smallest memory footprint. Configuring each layer multiplies memory savings by each of the objects in an interface – and the object count in a modern cluster can be surprisingly high. In a simple model of an 800×480 interface with a single background and only eight buttons, Altia found that RAM could be reduced by 50 percent and ROM could be reduced by over 0.5 MB by using hardware layers.

Simpler certification

As more critical driving data is being presented on screens, Altia’s customers are prioritizing safety as a primary tool chain requirement. Standards such as ISO 26262 ensure that code and processes meet the strict guidelines required for mission-critical applications, which adds a tremendous burden on developers who are already trying to compress development cycle times. Therefore, it is important that development teams are able to shrewdly minimize the code that needs to be certified.

The traditional way to accomplish this feat is to separate the code. Physical telltales and gauges are used to convey safety-critical information, while the driver information display provides supplemental information. As the screen in the cluster becomes a more integral part of the identity of the vehicle, automakers have cleverly blurred the lines between digital and analog information in the cluster. In some cases, this is done to the extent that it is difficult to perceive where the screen stops and physical indicators begin. In this way, developers can segment out the most safety-critical pieces of code that must pass extended certification.

A similar division is happening even on clusters that are entirely screen-based. Altia-generated graphics code can leverage hypervisors in modern RTOSs to provide ironclad separation between safety-certifiable software versus all of the remaining cluster software. You can even go so far as to have completely different operating systems on each hypervisor, which provides maximum safety and flexibility. This gives you the freedom to have everything drawn with software – providing a uniform look and feel – while utilizing the available CPU and thereby reducing cost and complexity.

Go native

There are many ways that development teams can create embedded graphics for an automotive cluster. Some coders use high-level libraries that have been force-fit onto an embedded system. Others employ weighty black box engines that interpret interface layout commands. Savvy development teams understand that the safest and simplest approach to graphics development is native C code.

Expertise and talent, as well as tools and processes, have been refined over many decades to produce the highest quality embedded code. What’s more, C code offers the compactness and performance needed for production embedded platforms. After all, these teams are not developing a web interface that is running on a PC – this is a deeply embedded device that must react immediately and deterministically in every scenario.

Modern clusters: Innovation opportunity

The modern cluster is an amazingly advanced area of technology in the vehicle, but it is not a high-powered PC that can be rebooted when things go awry. Safety and, just as critical, reliability are paramount. But the display in the dash is also no longer a simple, multi-line driver information display. The modern cluster is a unique challenge for automotive engineers who are pushing the boundaries of automotive user experience innovation. It’s important to balance usability and code certification requirements while optimizing graphics performance on limited hardware to achieve a safe, yet attractive, instrument cluster for next-generation models. Development teams face many challenges, but with the right tools and processes, they have the power to radically reinvent the cluster HMI.

Jason Williamson is Vice President of Marketing at Altia, Inc.

Altia

www.altia.com

@AltiaHMI