The basics of automotive cluster device

architectures and applications, part II

Deepak MahajanVIKAS AGARWAL,Arjun Pal Chowdhury,Neha Agarwal, - September 14, 2015

You can read Part I of this series here.

With the increased complexity of vehicle electronics, a large number of status information must be
displayed to the driver. The instrument cluster is the primary data source for the driver, delivering
information regarding a vehicle and its engine status. Given today's system complexity, it is
increasingly important to provide user friendly, lucrative, and cost-effective solutions that support a
wide range of automotive cluster applications. In this part of the series, we discuss:

● Cluster security requirement and application

● Device memory requirement
● Low power mode cluster architecture

Device security

Highly integrated automotive systems demand the highest safety and security possible. Secure
hardware solutions should have sufficient capability to protect application code and data storage
from illegal or unwanted access by hackers. Using secure hardware, application software can also
detect tampering of application code and data and take necessary action. Modules capable of
producing cryptographic functions can be used by application software to build such well-known
security specification as "SHE," which is globally accepted by big car makers like GM, BMW, VW,
AUDI, and more.

New technologies make everyday life more convenient: We shop, conduct banking transactions,
attend to life online, and use keyless systems for opening cars and doors. However, new
technologies often harbor new risks. Weak points in inadequately secured systems permit identity
theft and spying, data manipulation, or even counterfeiting.

Basic hardware security is required for a cluster device and advanced security concepts help make
vehicles more secure.

Basic security

Device authentication

Currently, when data is transmitted via air, just performing secure communication by encrypting a
message is not sufficient. Ensuring that the data received is from the authentic sender is also
important as devices should be able to prove that they are trustworthy. A unique identifier or even a
cryptographic identifier for a device today is not secure enough if it is completely generated by
software. Instead a trustworthy platform should be used that performs device authentication based
on cryptographic keys generated through a True Random Number Generator and performing the
comparison of the generated code with a highly secure pre-programmed code stored in a highly
secure memory region.

Secure boot

There is a possibility of a security threat by hacking into device boot code and bypassing all the
security checks during device boot-up. Thus, it is critical to secure the device boot process. Based on
the criticality of the application, the device may choose to implement a strict or a relaxed boot
check. As an example, in a strict boot check, the device may refuse to start up and may get stuck if
the secure boot fails, or it may continue with device operation and inform one of the ECU of the
secure boot failure which may then take any other desired action in a relaxed boot check.

Memory read/write/erase protection

It is critical to protect the memory region from being accessed via malicious code where the secure
information or cryptographic keys used for device authentication or other security operation are
stored. The secure memory region should only be accessible by the authentic code. The device
should be capable of self reset or indicate the security module of the device in case there is a
breach, or someone tries to access secure memory.

Secure debugger access

Security of a device versus testability is always a vulnerable area for the hackers. It is important to
provide the debug capabilities on the devices in case there is a device malfunction or misbehavior.
But since the debug access provides an insight of the devices and opens the device for certain
critical tests, it should be protected through some mechanism. The approaches usually used are
password protection with challenge-response mechanism, restricted debugging capabilities, etc.

Password protection

To allow access to the device’s secure modules and other critical memory regions, there is usually
password protection that is implemented. Further protection of access and availability of these
passwords is critical and can be implemented using a challenge response mechanism.

Security applications of cluster device

Immobilizer

The electronic immobilizer is used as a component of theft protection of automobiles. To protect the
malicious user from using a fake key, authentication takes place between the ignition key and other
electronic control units of the car. The authentication steps are as follows:

● When ignition is turned ON using the car key, the challenge response begins. A transmitter, i.e.
ECU (challenger) generates a random number using True Random Number Generator and sends it
to the car key. The responder (the car key) encrypts the random number using a secret
cryptographic key and sends back the encrypted message to the challenger. The challenger then
decrypts the encrypted message with the same secret key and compares it with the actual
 transmitted key. In this way the authenticity of the responder is validated. The entropy of the
random number generator should be very high; otherwise an attacker can fake the identity of the
responder by monitoring the encrypted message and sending it back to the challenger.

Mileage protection

Mileage fraud artificially raises the cost of used vehicles and can be controlled through odometer
protection. Mileage protection is achieved in security-based microcontrollers through:

● Preventing unauthorized access to the odometer unit through "SHE" based hardware solutions.
● The protected ECUs allow secure communication using challenge and response mechanisms
achieved through crypto keys and secure memory.

Component protection

Component protection again uses the challenge response authentication to identify the replacement
of automotive components, unintended by the manufacturer. A challenge-response is run between an
engine control unit (which will be a security master assigned by an algorithm during the start up
phase or it can be fixed assigned by OEM) and other components of a car. UID is sent to the Security
Master by each of the car components in encrypted form using a crypto key. If the UID doesn't
match with the internal database stored at SM end, it blocks the start of the engine.

Secure-on-board communication

The ECUs that communicate to the outside world and to the internal vehicle network, pose the
biggest risk for car security. These ECUs can become the part of the communication system over
which data is sent. An attacker can hack the communication bus and can manipulate the data on the
bus. This can be controlled by using strong cryptographic methods which involves complex and truly
random keys. Such keys cannot be retrieved just by monitoring the data traffic on the bus for long
enough.
● Passive Anti Theft System: An example could be a key immobilizer, which in case of challenge
authentication failure, can keep a fuel pump or starter disabled. The sensors that capture the RF
signals (encrypted ID sent by key) are designed to pick up only nearby signals to avoid car theft.
● Tire Pressure Monitoring System: Each tire has a pressure sensor which monitors the tire pressure
and sends the real time data to the ECU. It is possible to make hack the TPMS system if connected
to the network and make it think that there is some problem with the tire or the TPMS system.

Device memory requirements

Device memory requirements

SRAM (System RAM)

SRAM is the primary memory of the chip. It constitutes one of the major portions of the available on-
chip RAM on the device. It is mainly used to put the application code of the core responsible for
AUTOSAR related execution. It is also enabled with ECC protection for safety and quality reasons. It
is used along with a part of Flash to store the AUTOSAR application code. SRAM can also be used to
store graphics application code depending upon the use case requirement. The device also supports
a low-power mode, within which a portion of the system RAM remains powered in a state capable of
retaining RAM contents.

SDR/DDR SDRAM

It is the available off-chip volatile memory bank/RAM of the device with the DRAM controller
residing inside the device. The controller can support SDR, DDR2, and DDR3 type of memories. DDR
is primarily used to store graphics data and part of graphics application code depending on the use
case requirement. The application processor accumulates and sets up graphics commands that are
dispatched to the GPU for processing and display rendering. The processor writes the commands to
DRAM where the GPU fetches and executes the command. Also, it can be used to store the decoded
large images and fonts, etc., at the start-up time of the application. It can also be used for storing
processed graphics data for display, double frame buffering schemes, and graphics firmware
updates.

GRAM (Graphics RAM)

This is the other major portion of device on-chip RAM. For automotive instrument cluster chips
requiring the display of extensive graphics content, a dedicated memory for storing graphics
information is required. Graphics information (pixel information, graphics formats, text information,
animation information) stored in flash is first copied in GRAM and is used by the display controller,
GPU or the graphics application processor. It is also used for storing the data processed by the GPU
which can be fetched by the display controller to stream it real-time onto the display. It can also be
equipped with a ECC scheme, which can be flexibly enabled/disabled to serve the purpose of general
purpose RAM. Depending on the use-case requirement, it can be combined in conjunction with
SRAM by the user to store the application code with the flexible ECC feature enabled for data
protection. It can also be used by the GPU for fetching commands and to store the decoded large
images and fonts at start-up time, etc.

On chip flash

It is the on-chip non-volatile memory bank on the device. The flash is mainly used to store
application code (for both AUTOSAR and Graphics), various firmwares, and important look up tables.
The device initialization firmware is also part of flash. It is equipped with local page buffer storage
to support concurrent access by multiple masters with single cycle buffer hit response. Flash also
stores important device configuration information for device reset or boot-up. EEPROM emulation is
used to store run time permanent data into flash. For example, when the user switches off the car,
the odometer information is encrypted and stored into a flash location. It is also used to store
security related firmware and various security keys and to store such graphics related information
as static images, backgrounds, etc.

External serial flash

For advanced graphics applications, the on-chip flash may not be sufficient to store much static
graphics information for display onto a screen. To increase the on-chip flash size after a certain
point can impact the chip's die size and hence its cost significantly. An efficient solution is to put a
low cost external flash interface with the chip. The external serial flash is the off-chip non-volatile
memory bank of the device with the flash controller (for e.g. QuadSPI Flash Controller) sitting on the
device used to communicate with it. External Flash is primarily used to store graphics information,
which will be copied to either GRAM or SRAM before use. This graphic information can be vector
fonts (data), large images, etc., either in an encoded form (for e.g. RLE) or as it is. The other main
use is to store the GPU drivers as they are too large for device internal memory. These drivers will
be invoked by the application processor to communicate with the GPU hardware to perform graphics
operations. A display controller can also access data directly from external flash for display
purposes. Depending upon the use case requirement, the user can also choose to execute code or
support device boot. It also supports a multiple buffers feature that enables the display controller
and application processor simultaneously for data and code access.

The following figures illustrate a variety of memory use cases:

The graphics application processor will access the GPU drivers from external flash and generate
commands for GPU in Graphics RAM/DRAM. GPU will then read these commands and process them.
Finally, the display controller can read from GRAM/DRAM to display onto the LCD screen. GPU
drivers, if small in size, can be put in internal flash as well. GPU can also fetch data/commands from
internal/external flash. Static information (like background, static images, icons, etc.) can be fetched
by the display controller from the on-chip/external flash.

Large encoded images and fonts, etc. stored in internal/external flash are transferred by DMA to
RLE for decoding. The decoded data will be copied to DRAM/Graphics RAM by DMA again which can
be finally send on to the LCD display by the display controller.

Real time data, for example, a reverse camera stream will get buffered into the video input unit for
scaling, brightness adjustment, etc. and then put into Graphics RAM/DRAM. It can then be further
processed by the graphics application processor and stored back into DRAM/Graphics RAM. Finally,
it can be routed to the LCD display by the display controller.

Low power mode requirements in a cluster device

The key challenge of a cluster device is to minimize the average power consumption when the car is
idle, improving the battery lifetime of the car. When the car is in an idle state, i.e. the ignition key is
disengaged, the cluster ECU must perform basic housekeeping functionality, which is activated
periodically, such as the monitoring of the onboard power supply, performing basic computational
tasks on the monitored inputs such as filtering of results, making a comparison against historic
results, and more. Keeping the time clock on and calibrating the clock used for RTC are also
common housekeeping functions performed.

An intelligent device must ensure bare minimum power consumption of the device during the idle
phase. Standby mode or deep sleep mode are generally used to support this requirement. It is
incumbent on the designer to keep bare minimum functionality ON in standby mode to minimize the
leakage power of the device and at the same time ensure the seamless execution of housekeeping
functionality.

Most cluster functionalities such as display, motor control, and graphics core or real-time processors
are not required to operate while the car is idle. Hence a power supply can be permanently switched
off. In order to enable housekeeping functionality some basic modules like ADC, SPI, timers, and a
small processor must be periodically enabled. Hence, the device can have a provision to switch ON
and OFF the functionality required for housekeeping. There are few modules that always need to be
enabled. For example, the Real Time Clock (RTC) module and some memory array which keep some
important data and parameters for housekeeping functionality needs to be always ON.

The above is a conceptual diagram of a cluster device where the partition is based on low power
mode requirement. When the ignition key is engaged, i.e. the device is in full power mode, all the
switches (S1 and S2) are closed. In car idle state, S1 will remain open permanently and S2 will be
open and closed periodically during housekeeping functions. This architecture will help to improve
the average power consumption of the device significantly in a car idle state.

Conclusion

Today, the immediate challenge is to provide integrated solutions that are cost effective and
technically advanced to fulfill market requirements. The automotive cluster has transformed from
analog gauges to digital displays to integrated cluster infotainment solutions. The future trend will
be to move toward a highly integrated solution where basic cluster, infotainment, and advanced
driver assistance will all be integrated in a single device. Hence it is very important to understand
the basic architecture to know how they can be used to create an integrated cost effective solution
for the future.
Also see:

● The basics of automotive cluster device architectures and applications, part I

● Instrument clusters gated by power control