Hardware - Software Tradeoffs in Automotive Sensor Data Processing

By Chaitanya S. Rajguru and Praveen Kumar Pendyala

Abstract -- Sensor data processing is central to key automotive features such as safety. The complexity of the task continues to expand rapidly. Nontraditional approaches to system optimization may be warranted when designers wish to squeeze the most out of their cost, power and performance budget. This paper explores a wide range of implementation options for sensor data processing, and attempts to identify the ones most suited for various system goals. It then lays out specific recommendations for various needs.

I.    INTRODUCTION

Sensors are widely used in automotive systems to ensure safe operation and to improve performance [1]. There may be over 30 sensors in a vehicle constantly feeding data to the many electronic control units (ECU’s) on board. They help us monitor a wide range of real-world events and trends, such as engine temperature, fuel level, and the possible occurrence of a crash.

Automotive computing needs are real-time and embedded in nature, which impose real-time requirements on data traffic. The safety requirement for automotive systems is typically met through rapid and continuous sampling of data, through constant re-evaluation of the data against expectations and norms, and through redundancy (where possible). Performance requirements are met through high bandwidth, low latency, and rapid data processing.

All of the above requirements place heavy demands on the data acquisition system (including sensors and their connections to the ECU’s) and the data processing system (including ECU hardware and software). The combined computation and communication bandwidth can be significant [2]. This necessitates the use of multiple high-speed buses and powerful processors.

The automatic approach to meeting these requirements is to add more and more hardware and software. This is simply a linear expansion of existing systems. However, this increases the cost of interconnect and components, weight, power drain on the battery, and system development effort. It may be appreciated that this type of growth has its limits and will be sub-optimal as the feature set grows. More intelligent trade-offs of the computing tasks should yield better systems that can do more with less.

This paper presents one approach for better global optimization of automotive sensor data processing. The intent is to optimize the computation resources and time at the system level.

The rest of the paper is organized as follows. Section II lays the groundwork by clarifying the system designer’s intent. The trade-off options available to the system designer are then explained. Section III covers the main analysis of typical sensor data processing computation from first principles. Section IV discusses the pros and cons of various choices.

II.    SYSTEM DESIGNER’S PERSPECTIVE

A.    System Design Intent

Any attempt at improving a system needs to be based on and consistent with the system designer’s overall goal. Hence we first review the intent behind the design of the sensor electronics.

The goal of the sensor electronics is to gather meaningful information about the vehicle and its environment. The system then acts on that information to ensure safety and increase performance. Information-gathering requires the collection of continuous real-time data in huge volumes. This data then needs to be processed to condense it into information, and at higher levels, into knowledge and understanding, as seen in fig. 1. Finally, a wise decision-making entity puts this understanding to use. As we go up the information pyramid, there is a dramatic reduction in the volume of the communication messages and an increase in their value.

Fig. 1.  DIKUW Pyramid.

The system designer employs a wide range of tools to accomplish this data collection and processing. A bewildering variety of transducers is available to measure almost anything in and around the vehicle. Analog and digital sensor electronics converts this information into a digital form for further processing. The data stream is passed on to the ECU’s via a communication network. The data processing software that runs on ECU microprocessor systems does the higher-level analysis, trend comparison, and decision-making. The system designer selects the right hardware and software components and distributes the various tasks among them, so that the safety and performance features can be realized at the lowest cost.

As an example of a system, a road surface sensor may be measuring road surface height. Sensor electronics may transmit the data stream to the ECU hardware. The software may condense the data info information by converting the bit stream into physical height values and measuring their variation. The software may then convert this information into knowledge about the size of the road surface bumps by using vehicle speed information. Other software may use this knowledge into developing an understanding of the road surface, including surface hardness, quality, likelihood of traction loss, etc. The topmost software layer may then further tap its prior wisdom to make the right decisions for smooth suspension and traction control.

B.    Design Trade-off Options

The above example demonstrates a typical sensor electronics design. It is common for the data generated at the sensor to be directly transmitted to the ECU. The information, knowledge, understanding and wisdom layers are normally handled by the ECU software.

However, alternate implementations are possible. An example at one extreme is the use of artificial neural networks, where the information to wisdom layers are all combined into a configured hardware (or a static software) implementation. A more gradual change from the prevalent architecture involves moving the data-to-information conversion from the ECU software to the ECU hardware or to the sensor module. Within the sensor module, hardware functionality may be implemented in a digital or an analog domain, or in a combination of both. It is the latter architecture that we evaluate quantitatively in the next section.

III.    SENSOR DATA PROCESSING

We have focused here on the process of converting data to information. The implementation of higher-layer processing is tougher to move from the ECU out to the sensory periphery of the system, and is not in the scope of this paper.

Data processing to extract information can take one of several basic forms. Data from position sensors may be simply shifted and scaled to determine steering wheel position. Trunk lid sensor data may be thresholded to determine if the lid is open. Acceleration may be determined as a derivative of the speed. And available range of electric battery vehicles may be determined by means of integrating and averaging the total amount of drained charge over time.

This type of processing can be readily relocated from software to hardware, and from digital to analog domains. However, we need to determine whether this is useful and practical. This depends upon the cost, performance and power implications of such a change. We have tabulated these key metrics for several fundamental calculations. Three implementations are considered – in software, in digital hardware, and in analog hardware (where equivalent implementations are available). Table 1 consolidates the comparative data between the implementations.

TABLE 1: DATA PROCESSING PRIMITIVES

DATA PROCESSING FUNCTIONALITY	ANALOG H/W IMPLEMENTATION				DIGITAL H/W IMPLEMENTATION				DIGITAL S/W IMPLEMENTATION
	SILICON AREA (µm2)	COMPUTE TIME (ns)	COM-PUTE POWER (µW)	COMPUTE ENERGY (fJ)	SILICON AREA (µm2)	COMPUTE TIME (ns)	COMPUTE POWER (µW)	COMPUTE ENERGY (fJ)	SILICON AREA (µm2)	COM-PUTE TIME (ns)	COMPUTE POWER (µW)	COMPUTE ENERGY (fJ)
Offset	10000	30	125	3750	285.4	10	51.2	512	0	70	56571.4	3960000
Scale	14400	30	150	4500	820.6	160	147.2	23552	0	220	140727.3	30960000
Threshold	6400	20	100	2000	285.4	10	51.2	512	0	80	72000.0	5760000
Invert	14400	30	125	3750	321.1	10	57.6	576	0	70	56571.4	3960000
Delta	22500	30	125	3750	606.6	20	108.8	1088	0	80	72000.0	5760000
Min					463.8	30	83.2	832	0	80	72000.0	5760000
Max					463.8	30	83.2	832	0	80	72000.0	5760000
Average					2426.2	350	250	24580	0	400	158400.0	63360000
RMS					3603.7	520	646.4	95104	0	570	164842.1	93960000
Differentiate	562500	360	125	45000	1926.7	200	345.6	36224	0	250	145440.0	36360000
Integrate	22500	180	125	22500	463.8	20	83.2	832	0	70	56571.4	3960000

Several trends are visible from the table. Software implementations have no incremental silicon area cost, so are best when comparing component cost adders. Digital hardware comes next, and analog hardware last. (The possibility of reusing existing building blocks such as op-amps can only be explored in specific components and is not considered here.)

Comparing computation time, hardware implementations understandably perform better than software. Between analog and digital hardware, the latter comes out ahead more often than not.

Power and energy varies much more across the implementations. The software implementations consume more energy by orders of magnitude. Again, the analog and digital implementations show mixed results.

IV.    SYSTEM DESIGN CHOICES

We can now derive logical recommendations for the system designer within the trade-off options. Where hardware cost is most important, the software implementation may be selected. However, if calculation speed and latency are important (as in some time-critical applications such as air bag deployment), digital hardware implementations clearly do best. The only exception is the scale functionality, which is fastest in the analog domain. This can be a standard option for sensor analog processing chips.

Software implementations are noticeably wasteful of energy. In cases where energy consumption is most important, a hardware implementation is recommended. The specific functions dictate whether a digital or an analog hardware implementation is preferred.

V.    CONCLUSION

Novel optimization strategies for automotive systems have been offered in this paper. We hope they open up new possibilities of best-in-class features. In fact, these concepts can easily apply to many domains other than automotive, such as industrial, embedded and mobile devices.

This work may be further extended to actual implementations of components and systems, so that the theoretical benefits are realized. A deeper look into optimizing the higher-level abstractions of knowledge, understanding and wisdom may also lead to newer insights.

REFERENCES

[1]    W.J. Fleming, “Overview of automotive sensors,” in IEEE Sensors Journal, pub. Dec 2001, vol. 1, issue 4, p. 296-308.

[2]    G. Leen, D. Heffernan, A. Dunne, “Digital networks in the automotive vehicle,” in IEEE Computing & Control Engg. Journal, pub. Dec 1999, vol. 10, issue 6, pp. 257-266.

Chaitanya S. Rajguru received his B. Tech. in electrical engineering from IIT Bombay, India, and his M.S. in electrical engineering from Virginia Tech, USA.
He worked at Intel Corp. from 1992-2009 as a Circuit Design Engineer, Flash memory Architect, and chipset and graphics Design Manager. He currently is Associate Technical Fellow at KPIT Cummins Infosystems Ltd. in Pune, India. His research interests include computing hardware and algorithms, VLSI technology, energy and power in systems, and environmental aspects of technology.

Praveen Kumar Pendyala received the B.S. degree in electronics and communications engineering from Vellore Institute of Technology, Vellore, India, in 2001 and M.S. degree in electrical engineering from the University of Utah, Salt Lake City, Utah in 2004.
From 2004 to 2007, he was with Qualcore Logic, as a senior member technical staff, working on design of data converters, clock circuits and power management circuits. In 2007, he joined KPIT Cummins Infosystems Ltd., where he is currently a Technical Leader, working on design of data converters and high voltage power management circuits. His current interests are analog circuits.