Pergamon A. Rev. Control, Vol. 20, pp. 197-207, 1996

Olnternational Federation of Automatic Control 1997 Printed in Great Britain. All rights reserved

S 0 0 6 6 - 4 1 3 8 ( 9 7 ) 0 0 0 1 7 - 7 1367-5788/97 $32.00 + 0.00

Architectural Trends in Automotive Electronics

Uwe Kiencke, Timo KytglL Karl Joachim Neumann

University of Karlsruhe

Institute for Industrial Information Systems

Hertzstr. 16, 76187 Karlsruhe

Fax: 0049 - 721 - 755788

1 Abstract

The architecture of automotive systems is currently changing from a number of local, more or less isolated electronics to a functionally integrated distributed system which is linked by a network. This disengagement from local implementations is the platform for innovative control approaches in vehicles. It is supported by enhancements in microcontroller capabilities, due to the introduction of operating systems, co-processing, more efficient development process and by the application of artificial intelligence into automotive systems.

2 Introduction

Electronic technology is applied in automotive systems as a basis for the implementation of new functional features. The application of electronics has provided higher performance, more comfort, a higher safety level and less exhaust emissions for today's automobiles.

The cheap application of electronics depends on the fast progress of semiconductor technology. This means faster cycle times of logic components, growing complexity of integration and falling component prices.

New functions are still generated for automobiles, a process, which will probably continue during the next years. New control functions are needed to meet the ever tightening regulations for exhaust emission, the growing demands for comfort, the introduction of enhanced driver information and traffic control systems [1]. To be able to implement such new features, a further enhancement of the electronic components is necessary.

The limits for the application of electronics in automobiles will not only be determined by the progress of the semiconductor technology, but also by the ability of designers to handle the growing complexity of distributed automotive electronic systems.

In this paper, architectural trends are shown in microcontrollers ~C), in the application of real-time operating systems (OS), in networking and in a cost- effective application of artificial intelligence (AI)

approaches. Al techniques like e.g. Fuzzy-Logic and Neural Networks can thus partly replace conventional algorithms for control, filtering, classification, estimation etc..

The application of complex electronics also requires an enhancement of the design methods in order to shorten development cycles and to ensure the design q~Uy.

197

3 Distributed architectures

There are two alternative approaches to enter new control functions into an automotive electronic system: distributed or locally integrated (Fig. 1). The distributed approach emerged with the first in-vehicle networks in the '80s. By this approach, different electronic control units (ECU) are connected by a communication link through equivalent network interfaces [2]. In addition, autonomous intelligent sensors [3] and actuators can be connected to other units through the network. Networking is the basis for new top-down control approaches, independent of local ECU platforms. Examples are traction control, vehicle dynamic control and electronic torque control.

mmemt serum tmaomt Aaumor

Cm OPumc Oa-Oeem OteOnoe8 eJeam~ To~m c4m~

~tomoOve C4mmt F ~

Fig. 1: Distributed architecture of automotive electronics

In some cases, it turns out to be more cost effective integrating sepmme control functions in one local unit.

198 Automotive Systems

Such a local integration is especially attractive, when fast and frequent interactions between several control functions are needed. An example of this approach is the integration of engine and transmission conu~! into one ECU.

Another way to implement new additional features like on-board diagnosis, which very heavily depends on remote sensor data and pre-processed information fi'om other ECUs, is the introduction of a separate ECU.

The implementation of new control functions in automobiles requires a significant growth in ttC performance.

This is then the platform for integrated vehicle models and control schemes exclusively determined by their physical behaviour, rather than by their random local assignment to ECUs. Dislributed microelectronics give control engineers the chance to take over the lead in the development of innovative automotive systems.

4 Operating systems

A real-time operating system contains all administrative and organizational progrmns of a microcontroller and def'mes unambiguous interfaces. It is the software platform upon which application programs can be developed, and provides their execution environment. Like conventional operating systems the software architecture of real-time systems comprises the following main functional areas [4][5]:

• process management: management of tasks, including scheduling and dispatching of tasks,

• process interaction: co-operation, communication and synchronization;

• I/O-Interfacing; and • resource management, e.g. access control for data

structures or devices.

resources are managed by the operating system, so that the application programmer can entirely focus on his application specific problems rather than underlying system issues. Second, a decomposition of an unstructured application sot~are into interacting independent tasks, which are relatively simple and can processed quasi-parallel. This is supported by the multitasking facility of the operating system.

Fig. 2: Handling the complexity of an application

Such a structured and modular soft, rare implementation is a necessary condition for the reuse of existing software: extendability and portability (Fig. 3). Extendability often the modular functional extension of single tasks, as well as the integration of additional tasks. Portability allows the mmsfer of tasks from one hardware platform to enother one without modifications, e.g. portation of existing application software to the next product generation of an ECU. In automotive applications, extendability and portability should be independent of the supplier of the tasks or functions ("cohabitation"). This requires a standardization of the application progmn interface (API) of the operating system between suppliers and car manufacturers.

It must be remsrked, that in current real-time operating systems extendability and portability is only supported at a fim~ional level. The time behaviour of the altered system is not taken into account and must be adapted.

In a real-time operating system, timing constraints of the application tasks must be supported. Therefore current real-time kernels

• provide bounded execution time for most primitives, • maintain a real-time clock, • provide a priority scheduling mechanism, • provide special alarms and timeouts, • support real-time queuing disciplines, e.g. earliest

deadline first, • provide primitives to delay processing and

suspend/resume execution, and • include features to minimize the run-time overhead

incurred by the kernel, e.g. fast context switch, quick interrupt response time etc.

Real-time systems efficiently support application sofl~vare development.

The growing complexity of application software is managed by a structured and modular so/~ware. This cam be based upon the following two features of operating systems (Fig. 2): First, a separation of appfication specific so/~ware A i and general system software ~ . All

Co44al~aloa ~ z

Fig. 3: Co-habitation, portability and extendability of application soft, rare

Further requirements for operating systems are:

automotive real-time

economic use of RAM and ROM, angle control for cyclical and stochastic activation oftesks static configuration and scaling to support the entire range of target systems from the top-end to the bottom-end, e.g. 8 - 32-bit microcontroller, and operation from ROM code.

Automot ive Systems 199

Some trends in the current research in real-time operating systems are [4][5][6]:

• development and utilization of sophisticated scheduling algorithms, which explicitly take into account several conslralnts, e.g. timing, resource, precedence and importance constraints instead of a priority scheduling;

• development of real-time synchronization primitives supporting e.g. priority inheritance, priority ceiling;

• time-driven resource management not only for the processor, but also for memory, I/O and communication resources;

• adaptability of operating systems to a variety of user and system needs, e.g. selection of the time-driven resource management algorithms most suitable for a particular application or situation;

• real-time operating systems for multiprocessor systems and distributed systems;

• API standardization for real-time operating systems for automotive ECU; and

• support for fault tolerance.

5 Enhancement of pC performance

There are different alternatives to achieve the required growth of ttC performance. The shrinking of semiconductor design dimensions allows to increase the CPU clock frequency, which directly speeds up program execution. Potential problems with electromagnetic interference must be overcome.

The enhancement of the CPU architecture offers another possibility to increase ~tC performance. This includes the extension of the word length, macro insu'uctions, instruction pipelines and cache memories etc.. Pipeline and cache techniques might render predictability more difficult, which is one of the central requirements for real-time systems. As a successor to RISC architectures, so-called "Very Long Insm]ction Word" (VLIW) architectures will generate the next performance leap in processing.

The third way to boost ttC performance is to increase parallelism within the HW by embedding enhanced peripherals and co-processors on the chip. This approach is a current trend in automotive electronics, in combination with the other above mentioned enhancements.

CPU

2 - - [ - . . . . I

Ib

..FL_r--U..

Fig. 4: Peripheral services with a loose coupling

An Input Pulse Processing Unit continuously determines e.g. the period length of an incoming pulse sequence. A task in the CPU reads the last period length when required, and proceeds immediately to the next instruction without any waiting time. The other example is the peripheral generation of an output pulse sequence. Being ordered by a task in the CPU, the peripheral unit generates the pulse sequence autonomously. The task on the CPU can continue the execution immediately after the order has been sent.

Cases, where the parallel implemented services and the related tasks are tightly coupled, are more complicated. Fig. 5 shows an example of a peripheral implementation of an interpolation map. A task in the CPU would issue an order to the Interpolation Unit and must then wait for the interpolation result (z), before it can further Im)coed. The parallel execution of tightly coupled subtasks is reasonable, if it is much faster in a specialized peripheral unit in comparison to the main CPU.

CPU

S B ~

WNT FOR z .~ I

8END WNT z

I I I , . r t

I I

I' bmywNt ime of Ihemalc

5 . 1 Co-processing

A successful implementation of a subtasks in peripherals requires, that the subtask can be executed parallel to other activities in the CPU. This requirement is most easily met in cases, where the in parallel implemented services and the related tasks on the CPU are only loosely coupled. Two examples for a loose coupling between a peripheral service and the main program in the CPU are illustrated in Fig. 4.

Fig. 5: Peripheral services with a tight coupling

The are also techniques to compensate the busy wait time of the task. The busy wait time of the task can be shortened, if some instructions, which are independent of the interpolation, can be placed between the SEND and WAIT instructions. An other way to compensate the busy walt time is to utilize it for other tasks waiting to be executed on the CPU. This requires the task switching feature of a real-time OS.

200 Automotive Systems

5.2 Enhancement of peripherals

Fig. 6 shows an eventual future pC architecture containing enhanced peripheral units on the chip. Most of such peripherals already exist today, but arc not yet used in combination for an integrated control approach.

e m m a ~

Fig. 6: Enhanced pC structure

A Digital Signal Processor (DSP) is a very useful peripheral co-processor for many real-time applications. Fig. 7 shows the procedure for a distance measurement based on the Cross-Correlation of the transmitted and reflected ultrasonic signals. The Cross-Correlation- Function (CCF) shall now be implemented as a Matched-Filter. The coefficients of the Matched-Filter (y(i)) represent the reversed transmitted test signal. The distance (d) to an obstacle can be determined by the location of the peak in the CCF-Signal, which indicates the delay (~) to the arrival of the reflected test signal (see Eq. I-3). N represents the order of the Matched-Filter.

d

DSP signal u

o i i t i i i t i i t i i i i i i i i t 1 i i , i I i i I l T i l I l l i l I i i l I , I I l I I

~ " ' - - N =,

k

CCF

TTTTTT T''','" T

k*

. . . . . . . . . 1 1 1 1 ! , , I i i

I k •

i

Fig. 7: Distance measurement on a DSP

CCF(k) = ~ u ( k - i ) .y( i) i . . 0

O )

~ = ( k ' - N ) ' T (2)

T d = ~•c,~ (3)

An I/O-Pulse Processing Unit can further enhance pC performance. It measures different quantifies, such as the period intervals for an incoming pulse u~luence, and it generates output pulse sequences for various porposes. One succefaful exemple is the Time Processor Unit (TPU) from Motorola [7], which contains a group of enhanced functions in a microcoded fashion.

As an example for networking, the CAN protocol covering the two lowest OSI levels is currently one standard for in-vehicle networking. Implementations of the CAN protocol are available by numerous smniconductor suppfiers as stand-alone comrollers or as peripherals integrated on a pC. Futme implementations of network controllers will probably be more progmnmable and will additionally contain communication services of higher levels.

Fuzzy Logic and Neuronal Networks are still insignificant in automotive applications, but their use will dramatically grow in the near future [1]. Co- processor implementations of Fuzzy Logic and Neuronal Networks is a key approach to speed up their execution times over pure software solutions.

An OS Support Unit reduces the overhead for OS calls and speeds up the task switching. The OS calls might be implemented in firmware, i.e. as macro routines, which are interpreted from a Micropmgram Sequencer (Fig. 8). Such a feature is already introduced e.g. at the NEC microcontroller pPD78602 [8]. Many pCs offer an instruction for a fast task context switching (i.e. dispatching), which is mostly based on the use of register banks containing task contexts. The actual working context of the CPU is exchanged to a new one by simply selecting the respective register bank.

m m l

' % ,

Fig. 8: On-chip OS support

The complete task switching consists of two different parts: the determination of the next task to be executed and the context switching. The OS support might be further enhanced by a Scheduler Unit, which is

Automotive Systems 201

not available on current ttCs. When new tasks become ready during the execution of a current task, the Scheduler Unit continuously determines the next task to be executed. The ranking of tasks depends on the scheduling policy used (e.g. static priority-driven or earliest-dendline-first scheduling), which is implemented on the Scheduler Unit.

After determination of the next task to be executed, the Dispatcher Unit loads the respective task context. If that context is not available in one of the register banks, it must be transferred from the main memory into one register bank. The register bank containing the context of the next task is identified to the CPU core.

Scheduling policies can be classified to be either pre-emptive, i.e. the task switching is completed through the context switching as soon as the context of the new task is available, or non-pre-emptive, i.e. the context switching takes place, when the current task is blocked or gives up.

After switching to the new task context, the Dispatcher Unit can store the old context into the main memory, thus making place for an other task to be executed in the future.

By means of an OS Support Unit, task switching time is reduced to context switching.

6 Open Systems in Automotive Networks

In a distributed control system, several controllers (stations) are connected via a communication link (Fig. 9), e.g. electronic control units within an automobile. Generally these control units are supplied by different companies, and they have different microcontroller architectures. For the connection of distributed system functions, stations exchange messages with standardized interfaces. A uniform network management guarantees the safe operation of safety-relevant, distributed systems [9].

Commul~=li~n

I I s . , = , [. s. 3

| [ = , I " -

C.~,~umem

Fig. 9: Distributed control system

The development costs for the communication and network management soi~vare may be significantly reduced, if the interfaces and procedures are standardized not just within one subsystem, but for the entire distributed system. The software should be implemented in a uniform operating system. In addition, operating systems with uniform interfaces offer different application programs available from various suppliers

which co-exist in a singk processor. In that way, the multitasking approach serves as m efficient means to cut costs.

The project "Open Systems and Interfaces for Electronics in Cars (OSEK)" is a joint project in the German automotive industry. The current OSEK consortium is made up by the following companies: BMW, Bosch, Daimler-Benz, Mercodes-Benz, Opel, Siemens and VW with the Institute for Industrial Information Systems of the University of Karlsruhe a s coordinator. An extension to the French automotive industry is currently under way. OSEK aims to specify an open architecture for communizing vehicle systems [10][11]. This architecture comprises (s. Fig. 10):

• Communication (Dam exchange within and between Control Units);

• Network Management (Configuration determi- nation and monitoring); and

• Renltime Executive (Operating system for Control Unit software).

RmdUme Execut~e

_ _ - - - - < ~ . ~ _ -~ ]

]

Communication Media

Fig. 10: OSEK architecture

With OSEK this expensive development investment is needed only once, and it is possible to re- use it with minor modifications for various applications.

Particular tergets of OSEK are:

• company-independent specification of interfaces, functions and protocols for Communication, Network Management and Realtime Executive;

• specification of a hardware- and software- independent user interface, which enhances portability and re-usability of application programs;

• efficient architectural adaptation to respective applications by reconfiguration and scaling; and

• functional verification and implementation of prototypes in selected pilot projects.

202 Automotive Systems

It is not the aim of OSEK to engage into an implementation of products. These should be left open for e.g. so/~are houses or microconwoiler manufacturers.

Resulting advantages are:

• significant reduction in development costs and time, • enhanced quality of ECU software, • integration of functional software modules Dom

different suppliers into one microcontroiler becomes possible, communication link between ECUs with different controller and network architectures, and increased functional performance of the entire vehicle by using all distributed resources and information.

The OSEK sub project communication specifies interfaces and protocols for in-vehicle communications. This comprises communication:

• between interlinked conUx)l units; • within control units; and • between control units and peripherals.

The control-unit software is thus simplified and can be re-used. The standardized interfaces keep the application software independent of special network protocols, such as CAN, ABUS, VAN, J1850, K-BUS, P-BUS, I-Bus etc.). OSEK communication can be provided for different protocols and microcontrollers.

The reliability and availability of the communication link is guaranteed by an integrated network management. Its essential services are:

• defined and synchronized initialization of the network communication, determination of the configuration. Application tasks can only start their operation, after all data transmitting stations are fully operational.

• continuous configuration monitoring, detecting the addition or the eventual failure of stations. Changes in configuration are relayed to the application layer, where a functional reconfiguration must be decided (e.g. graceful degradation).

• defined and synchronized transfer of the network into the "sleep mode".

7 Design

%1 Integrated Development Process

The aim of an integrated development process is shown in Fig. 11. The commercial contract between a car manufacturer and a supplier usually contains a functional specification which is recursively more detailed, until it describes all requirements of the contracted subsystem. The MSR project (Messen, Steuern, Regein, i.e. Measuring, Regulating, Controlling), another multi company project in the German Automotive industry, s u ~ this co-operation between car manufacturer and supplier [12][13]. The

aim here is an enhanced development efficiency by an improved information exchange between car manufacturers and their suppfiers, on the basis of a common procedural model and uniform interfaces end tools. The MSR framework allows for the simulation of functions in advance, so that the subsequent development work necessitates significantly fewer modifications of target functions. The final MSR specification is done on the basis of the OSEK interface, From there, functional prototypes can be built and tested in vehicles. The suppliers use the same basis to develop their electronic control units for production purposes. Today's extremely costly and error-prone barrier between prototypes and final products is thus overcome.

Commen:~ Corm~

J

{e.g. MSR)

1 e.g. OSEK-INTERFACE

]

C.oMr~ Un~ ]

Fig. 11: integrated development process

When several different suppliers must co-operate to integrate their individual subsystems into a complete system, the MSR/OSEK approach is even more beneficial (Fig. 12). Since the OSEK interface can integrate end products together with prototypes, different time scales or eventual time delays of one supplier no longer impede vehicle tests of the complete system at the car manufacturer.

Uniform Spectficatk~n of System Functions (e.g. MSR)

r J ' 1 • ~, , • ~, ~, e.g. OSEK4NTERFACE

Prototypes

Supplier A Supplier S Supplier X Supplier Y

Fig. 12: Integration of automotive systems

Automotive Systems 203

7.2 Hardware-Sottware Co-l)esip

The ever-growing functionality and complexity of automotive electronic control systems also requires better design methods. The main influence factors on the design process are represented in Fig. 13. Automotive control applications include time consu'alnts, which must be met by the designed control system. One possible time constraint could be, that a task must be completed before a specific time limit.

application HW cost time ~ requirements constraints

various application implementation functions poss~l~des

for HW/SW platform

Fig. 13: Factors influencing the design of electronic control systems

This rather complex cost-performance-problem makes it very difficult to design hardware and software separately. The integrated approach is called hardware- software co-design [ 14].

Fig. 14 shows the different phases of the complete hw-sw co-design cycle. During a first system design step, an optimal hardware-software partitioning is determined, allowing to do the actual hardware and software design separately in a conventional manner.

~ --R~:~;~--: specification ',

, r ~ - - - ~ - - " 6 e ~ , ~ . . . . ',

!

I

Fig. 14: Hardware-so/~ware co-design

We therefore concentrate on the system design phase of the hw-sw co-design, which is illustrated in Fig. 15.

Functional , modelling

I

- ~ ; o ~ r ~ : modelling ,

modelling ,'

Joint HW-SW-modell

, ~"-~.,.._~'~ / " " ~ _ ~ High-level I • • I , ~ ~ s ~ i n ~ , ~ ,

. . . . . t . . . . . . . . . . . . . . . . . . . . . . . . '

Fig. 15: System design

"/.2.1 Functional modelling

In this step, the behaviour of the application is modelled including functions for signal conditioning and network communication, if existing. In addition, eventual arrangements for fault tolerance are entered into the functional model.

Beyond pure application functions, the interaction between functional units and operating system (OS) services are described. By this, time constraints, events and execution sequences can be included in the model. As an example, an application event may have a certain repetition characteristic, such as:

• periodic The succeeding activating events appear after a constant period.

• quasi-periodic Only a minimal time interval between any two events is known.

204 Automotive Systems

aperiodic No exact quantities (like in the above cases) are known.

For tasks, which are triggered by events, a certain execution response characteristic is required. The different cases can be defined how to deal with the application specific time limit of tasks:

• hard An exceeding of the time limit is not allowed.

• medium Exceedings of the time limit for a task are allowed for • certain portion of all activations.

• soft No time limit exists. The task is executed as soon as possible without violating the response characteristics of other more critical tasks. Average execution statistic can be derived.

7.2.2 Procmm-oriented modelling

A process-oriented model describes the interaction between the processes (i.e. tasks) in a system (see Fig. 16). The process-oriented model can be derived from the fimctional model by grouping functions into processes, which represent units, that can be executed in parallel. Processes are executed only quasi-parallel by one processor unit, requiring the definition of suitable scheduling strategies.

7.2.3 Hardware-or:amted modelling

This design phase includes the performance modelling of different hardware components, which form a pool of possible resources. Components are chosen from this pool and processes are assigned to them for execution (Fig. 16). This is made in accordance to the performance goals and cost requirements. The hardware-software partitioning can also concern the operating system. The scheduler might e.g. be implemented on a separate resource significantly speeding up computation.

HW unit 1 H W unit 2 HW unit 3

Ai App4h:aUon preceu

Si Process for signal conditioning

Ni Process for network communication

~:~ Mslming of processes to • processor or • logic unit

I I /0 inter~=D

Fig. 16: Hardware-software partitioning

The execution of a process group on a proceum (i.e. software huplementation) is controlled by a scheduling algorithm, which can be derived acco~mg to the available repetition characteristics of the activating events and the required response characteristics of the proc~.sas.

7.2.4 Analysis

The result of the previous modelling is a joint hardware-software model This model can be analyzed in three different ways. TheJtmetional analys~ concerns the bchavionr of the system. It includes e.g. a deadlock investigation.

The performance ana/ys/s exams, if the time constraints of the hardware-software system are met. The analysis needs the following input information for each process, which is derived from the previous modelling phases:

* execution form: parallel or quasi-parallel e execution time using the chosen active resource

(in case of a software implementation, a 100% availability of the resource is assumed for the execution time estimation)

s time limit (if exist) . repetition characteristic of the activation signal • response characteristic (including the percentage

portion for the allowed exceedings of the time limit by a medium response c ~ c )

For processes having a hard response characteristic, • 100% guarantee for meeting the time limits is needed. This leads to a worst-case arithmetic analysis. In case of a quasi-parallel execution of a process group, the chosen scheduling algorithm has a central role by the determination of the worst-case situation.

For processes with a medium response characteristic, exceedings of the time limit for a task are tolerated for a certain portion of all activations. This performance requirement is examined by a statistical analysis. E.g. the simulation can be performed upon the basis of an enhanced Petri-Net, which is derived from the process..oriented model. In case of a statistical performance analysis, • probability distribution (e.g. Poisson) has to be additionally defined for quasi-periodic and aperiodic task activation signals.

Obviously, both arts of the performance analysis are needed for a system including processes with hard and medium reslxmse characteristics.

In addition to the functional and performance aspects, the cost requirements can be examined by acost analysis.

If the result of this analysis does not meet the design goals, another iteration cycle of the system design must be made by retoming to one of the modelling steps. When the result of the analysis is finally positive, a more detailed design of the hardware and the software are performed separately,

A u t o m o t i v e Sys tems

Hardware-soft'ware co-design may be applied either by a semiconductor supplier or a customer to determine the $tC architecture for a specific application

• or a market segment of applications.

205

8 Artificial intemgenee in automotive systems

In automotive electronics, the most relevant Artificial Intelligence (AI) techniques are expert systems, Fuzzy Logic and Neural Networks. Cm'r~t use of AI in automotive applications is still rare, but the potential of AI techniques in automotive ~plications is already evaluated in many research laboratories.

The most probable application areas for AI tec.~miques are diagnosis, co-pilot systems, vehicle dynamic systems and traffic control systems. Two application examples are presented below for Fuzzy Logic and Neural Networks.

8.1 Fuzzy estimation of car veleeity [15]

Fig. 17 shows the schematic structure for the Fuzzy Logic based estimation of car velocity, which is derived from a conventional Kalman-Filt~ approach. The four wheel speeds, which are used as inputs for the Fuzzy System, are obtained by pre-processing the wheel rotational speed signals. Additionally, an integrated acceleration signal (Va) and the estimated car velocity (vfu z) of the previous estimation cycle are made available to the Fuzzy System.

]

w,, v,, ~ ~" [ k , - v , t~ v, SYSTEM k.

• V, k,

Fig. 17: Estimation of the car velocity

The Fuzzy System determines the weighting coefficients for the five input velocity signals. The estimated velocity is then calculated as a weighted sum.

The structure of the Fuzzy Estimator is shown in Fig. 18. It consists of two cascaded separate Fuzz3, Systems. The relative differences between the wheel velocities and the estimated velocity of the previous cycle Vfuz(k-1) (see Eq. 4) are the inputs of the first Fuzzy System. The relative difference between the acceleration integral and Vfuz(k-I ) is used in the fu'st Fuzzy System only to recognize measurmnent failures of the wheel sensors.

Fig. 18: Fuzzy System

v,(k)-v~(k-1) (4) delta-vi(k) = V,..(k- I) • 100%

Be~,.._se the wheel r o~ona l speed signals don~ allow a plausible estimation of the car velocity under braking conditions, an other Fuzzy System using deita_v a and the weight coefficients as inputs is cascaded with the tint one. The second Fuzzy System delivers the weighting coefficient for the acceleration i n u ~ 0,a).

A correction of the estimated velocity is needed in case of cornering (see Fig. 19). A third Fuzzy System is used to recognize a cornering condition. The recognition is based on the difference between the yaw rates determined for the front and rear end of the car. The Fuzzy System output delivers the linguistic variable "bend", which contains a probability expression for cocnering. The estimated velocity is then corrected with the yaw rate as ~own in Eq. 6.

•t•r bena ~

¥I v i

Fig. 19: Fuzzy Systmn

Yaw rate determination:

iF, = (v~ -vn ) /b , b= wbeeltrack (5.1)

v,. -- ( v . - v , ) /b

~__.(9vf+ ~, ~/2 (5.3)

Corr~ted velocity:

Fig. 20 shows estima~n results in snowy conditions. The reference velocity was obtained by using a Korrevit measurement insmunent available on the market.

206 Au tomot ive Sys tems

. - : ,, . . . . . . . . . . : . . . . . . . . .

V : / ' : : : : L : " : / : : : : :" ,/

i . ~ 40 45 SI f~ 60 ~ 70

"l'ln~ / el~

"}i!:i!ii -

"T'~e / ~

Fig. 20: Estimation results in snowy conditions; top: Vfu z and vref, below: Vfu z - vref

8.2 Airbng release control with n Neural Network [ 16]

Fig. 21 shows the structure of the airbag release control. The vehicle acceleration and it's derivatives are used as input signals. An alrbeg release algorithm performs a crash classification and decides whether the airbeg should be released. If necessary, the "Fire" signal for the airbag release is generated.

Feature ~-~ Release I Fire extraction ~ algorithm j

~"ReJoase algorithm~

I I I

f I

Fig. 21: Basic structure of airbag release control

An airbag mlmme algorithm should ensure, that the airbag is mlmmed at the optimal time point. The bag must be fully inflated before the passenger's head has moved 125 mm forward in a crash situation. The inflation of the bag typically requires about 30 ms (tAIRBAO) represented in equation (Eq. 7) for the optimal release time (tz).

t, = t(A~ = 125ram)- t~o (7)

An alrbag release algorithm should additionally deliver a decision signal, which stays consumt over a certain time period. It must be robust in respect to noise and to the variation of the input signal amplitudes.

A conventional decision algorithm is now replaced by a Neural Network. The Neural Network classifies the input vector of the chosen signal features to the output value "Fire" or "No-Fire". The network type, used in this application was a Multi-Layer Percaptron with Backpropagation u'alning (Fig. 23).

wo.,) W(kJ) WO.k) i I I

e(k)

v t

~ L l ~ r t

tOO

oulp.t I:mm

tmsr t

Fig. 23: Multi-Layer Percaptron with Backpropagation

In general, the Neural Network implements the calculation of a multi-level weighted and normalized sum of the inputs. This sum forms the output value of the network. The weights for the neurons are determined off-line during the training phase, which is based on representative data from car crash tests.

Compared to conventional classification algorithms for airbag release, the Neural Network delivers similar results. The Neural Network has, however, the advantage, that the complicated determination of thresholds can be omitted. This means a significant saving in development costs and time. Additionally, Neural Networks are more robust against signal disturbances.

The input signal features are chosen in the design of the release algorithm (Fig. 22). Conventional decision algorithms use linear combinations of the input signal features end compare them to thresholds, which might be variable in some cases.

u mmm~ urn-4 mWNm ~'~

f ' t , A , ] £ ' m - - ' l j o . - , . . . . , - - = - . i

Fig. 22: Design of algorithms for airbag release

9 Summary

The various changes in automotive electronics are advancing this field from just another application segment of electronics to a trendsetter in control engineering and in development methodology. The attraction of automotive electronics is in it's combination of broad variety of disciplines, such as automatic control, computer science, software technology, distributed systems theory and design methodology. In this paper, examples are presented for each field.

Automotive Systems

10 References

[I] J.J. Paulsen, "The state of automotive electronics in the year 2000: a perspective of the North American marketplace", IMechE, C391/KNI, 1989.

[2] H.-J. Mathony, K.-H, Kaiser, J. Unruh, "Serielle Kommunikation zwischen Steuergeraten", Proceedings of Elektronik im Kraftfahrzeugwesen, Esslingen Germany, Expert Verlag, voL 437, Jan. 1994.

[3] F. Heintz, E. Zabler, "Application Possibilities and Future Chances of "Smart" Sensors in the Motor Vehicle", SAE Technical Paler No. 890304, International Congress and Exposition, Detroit, Michigan, 1989.

:~[4] K.G. Shin, P. Ramanathan, "Real-Time Compu- ting: A New Discipline of Computer Science and Engineering", Proceedings of the IEEE, Vol. 82, No. 1, Jan. 1994.

[5] Ramamritham, K., Stankovic, J.A., "Scheduling Algorithms and Operating Systems Support for Real-Time Systems", Proceedings of the IEEE, Vol. 82, No. I, Jan. 1994.

[6] J.A. Stankovic, "Real-Time Computing Systems: The Next Generation", Tutorial Hard Real-Time Systems, IEEE, 1988

[7] Time Processor Unit Reference Manual, Motorola, 1993.

[8] S. Matsubara, T. Kuwahara, F. B. Gerhard, "On- Chip Realtime Operating System for the Engine Control Systems", SAE Technical Paper No. 900780, International Congress and Exposition, Detroit, Michigan, 1990.

[9] U. Kiencke "DisUibuted Realtime Processing in Automotive Networks", SAE Technical Paper No. 900696, 1990.

[10] H.-J. Mathony, K.-H. Kaiser, J. Unruh, T.Raith, T. Thurner, "Open Systems and their Interfaces for the electronic in Cars - OSEK", 13. Tagnng 'Elektronik im Kraftfahrzeug" im Haus der Technik, Essen, 1993.

[11] U. Kiencke, et al. "Open Systems and Interfaces for Distributed Electronics in CARS - OSEK", SAE Technical Paper No. 950291, International Congress and Exposition, Delroit, Michigan, 1995.

[12] K.-G. Besel, T. Hirth, "Design systems for the MSR.Project", (German-language), VDI-Berichte Nr. 1009, p. 503-516, 1992.

[13] J. Leohold, "The MSR-Project: Tool support for new ways of cooperation between vehicle manufacturer and supplier", (German-language), VDI-Berichte Nr. 1009, p. 491-50I, 1992.

207

[14] W. H. Wolf, "Hardware-Software Co-Design of Embedded Systems", Proceedings of the IEEE, vol. 82, no. 7, July 1994.

[15] S. Zink, "Einsatz yon Fuzzy-Log& zm. Schatzung der Fahr~euBe~hwindigkeit", diploma thesis, flIT, University of Karismhe, May 1994.

[16] (3. Now~, H. Gering, M. Ostertag, "Lemfahige konnektionhtische S ~ in der Automatisier- ungstecimik", Automatisierungstechnik, 7/I 994.