How to control automotive complexity

Integrated driver ‘cockpits’ are becoming more important for the next generation of car buyers, who want to see information freely shared between different systems inside the vehicle, and brought to the attention of the driver when necessary.

In some cases the traditional separate instrument cluster and infotainment screens are already being combined into one large display. In others, involving multiple display screens, there is already a need to share information generated from multiple sources within the vehicle, such as navigation images, camera data, audio feeds and advanced driver assistance systems (ADAS) sensors.

These data-sharing requirements have required new design approaches for the embedded software platforms employed, and new approaches to testing and safety approval.

Digital displays

The continuous improvement in digital display technology, with higher‑resolution screens available at lower cost, means they are becoming available for the mass market in applications.

The current generation of instrument clusters are so-called hybrid, combining mechanical dials with small digital in‑built panels. These are gradually being replaced with fully-digital panels, as these units become financially viable, with appropriate quality and performance.

The fully digital panel offers several advantages over its mechanical predecessor, including dynamic reconfiguration to support different driving modes or information preferences, and plenty of scope for future vehicle personalisation.

Software updates over the life of the vehicle mean that the display application could be upgraded to offer new features and functionality, potentially opening additional revenue streams for vehicle manufacturers. A typical architecture stack for a digital cluster is shown in Figure 1, above.

Single display data consolidation

A large screen display, such as the example in Figure 1, can be visually attractive but presents big challenges for the embedded software designer.
As the screen resolution increases, a more powerful graphics processing unit (GPU) is required to keep the screen refresh flicker-free, with associated optimised driver software.

A performance of 60 frames per second is generally acknowledged to be the minimum required to allow comfortable viewing.
Displaying a wide selection of complex graphical objects or video feeds from different sources is also a challenge – how to successfully arrange the information into a single display, and allow for appropriate partitioning of safety-critical and so-called normal‑world data.

With an ever-increasing emphasis on safety, touch-screen based systems become less attractive when there is a large amount of visual data to communicate to the driver. System controls through steering-wheel buttons, gesture and voice commands are preferred as they reduce distraction for drivers.

Organising the complete application stack, from hardware to board support packages, operating systems, and user interface (HMI) applications typically involves contributions from different technology providers.

Safety-critical architectures

When it comes to the embedded architecture, the safety-critical elements in any design need to run on isolated safety-certified operating systems, with clear separation from ‘normal world’ functions that could compromise them through interference.

Vehicle manufacturers will typically request that ‘safety artefacts’ be supplied by embedded software providers, along with software deliverables. These artefacts can include proof of testing, exhaustive documentation on all modes of operation, including failure modes, and traceability back to the software requirements.

The higher the ASIL safety-rating, the more rigorous the validation and certification process, and the resulting cost of the embedded software components. To adequately meet the most stringent ASIL D safety requirements, a fault-tolerant design with built-in software and hardware redundancy is needed.

At the system level, this can mean duplicate connection paths for signals, duplicate hardware and fail-safe modes of operation. At the embedded software level, the safety architecture will involve separated operating systems, process monitoring watchdogs and alerts that are triggered in the event of any detected anomalies or failures.

Consolidated ECUs

A modern luxury car is likely to contain 60 to 100 electronic control units (ECUs); a variety of operating systems ranging from simple schedulers; and real-time operating systems (RTOS) through to complex multi-function Linux TM-based operating systems or similar embedded platforms supporting communication gateways, domain controllers, infotainment and driver information systems.

The trend to consolidate functions is well under way in the automotive industry, and by combining some functions, wire-harness weight and connection complexity can be optimised. It may be possible to eliminate some ECU hardware, saving overall cost and component count. Software application complexity brings a challenge for testing and certification – the more lines of code to test, the higher the risk of missing a use-case, or exposing unexpected behaviour.

Applying decomposition to embedded software allows safety‑critical components to run in isolation, on a stand-alone safety‑certified operating system, while more complex, normal-world components can run on a complex operating system such as Linux TM, which can be hosting rich graphics support and complex applications.

To provide safety certification for an operating system means checking all possible responses for any given set of inputs. For high-end operating systems, such as Linux, the number of possible states and responses becomes very large, and meeting exacting test and certification standards is time‑consuming and costly.

By reducing the size and scope of an operating system, the safety certification process becomes more manageable, and mixed-domain architectures will allow small-footprint, safety-certifiable operating systems to operate alongside more complex domains based on Linux or other multi‑functional operating systems.

Applications such as instrument cluster displays need to integrate with vehicle communication systems, passing data via CAN, CAN-FD, FlexRay and Ethernet communication networks.

Including an automotive open system architecture (Autosar) software communications stack running as a separate, secure domain allows vehicle performance information to be collected and passed to the instrument cluster.

The combination of different embedded domains, with secure communication channels between them, provides a scalable mixed‑safety platform that can meet the high‑performance rich graphics expectations of consumers, as well as the safety-critical requirements of the automotive industry.

Techniques for information sharing

Several mechanisms exist for sharing information either between separate physical ECUs, or within a single ECU hosting multiple applications converging onto a single display.

High bandwidth bus architectures in the next generation of vehicle designs allow video and other large‑size graphical data objects to be quickly moved between nodes on the vehicle bus.

These mechanisms include shared memory, accessible from both applications, an inter-process communication mechanism (IPC), or a secure message protocol such as DDS (data distribution service) or RPMsg (restricted permission message).

A shared memory approach offers high data rate throughput, and is often favoured for graphics-based applications.

Eye-catching complex displays in vehicles are becoming a differentiating selling point for manufacturers, and new techniques are needed to combine 2D/3D graphics with safety-critical information.

Applying new thinking to embedded software frameworks allows safety‑critical and normal world applications to coexist.

Mixed‑criticality embedded architectures with capable HMI solutions have become very popular with automotive designers, and are scalable to meet the needs of the next generation – and increasingly autonomous driving – vehicles.

Mentor has collaborated with HMI provider Socionext to create safety-certified consolidated information displays.

Socionext’s ISO26262 certifiable functional safety module Candera Safety can be used to display safety-critical content according to Automotive Safety Integrity Level (ASIL) A or B and provides safe second-path rendering.

All included components are developed following this standard and Candera allows rendering of safety-critical graphical content onto a visualisation layer dedicated to functional safety.

The display architecture allows the safety-critical application to be executed within Virtual Address Space (VAS) dedicated to ISO26262 ASIL B rendering.

Table 1 : Connection mechanisms for high data-rate ECUs

About The Author

Andrew Patterson is business development director for Mentor’s embedded software division, specialising in automotive solutions (Mentor Automotive)