modern automotive electronics from an oem perspective

MMK

TRITA-MMK 2003:09ISSN 1400-1179

ISRN/KTH/MMK/R-03/09-SE

Modern Automotive Electronics from an OEM perspective

by

Ola Larses

Stockholm

2003

Technical Report Mechatronics Lab, Department of Machine Design

Royal Institute of Technology, KTH S-100 44 STOCKHOLM

MMK

Technical Report TRITA-MMK 2003:09

ISSN 1400-1179 ISRN/KTH/MMK/R-03/09-SE

Modern Automotive Electronics from

an OEM perspective Machine Design KTH

Mechatronics Lab

March 2003

Ola Larses {[email protected]}

Abstract

Modern automotive systems are rapidly becoming highly defined and characterized by embedded electronics and software. With new technologies in the vehicle the industry is facing new opportunities and also new challenges. Electronics have improved the performance of vehicles and at the same time, new more complex applications are introduced. Examples of high level applications include adaptive cruise control and electronic stability programs (ESP). Further, a modern vehicle does not have to be merely a means of transportation, but can be a web integrated media centre.

Based on the idea that OEMs should stay vehicle centric, the major problem for OEMs is integration. The integration contains internal integration of vehicular systems, as well as external integration to allow media developers to gain access to the passenger cabin.

In order to cope with the introduced complexity, new designs and processes are necessary both for hardware and software architectures. Many new functions are introducing autonomy in safety critical systems like brakes and steering which introduces requirements for dependable systems. The integration requires a design process that creates well defined systems supported by modeling and validation techniques. Current trends indicate that more hierarchical architectures will be utilized and also more high level modeling of system functions. A good integration would be supported if open industry standards and efficient power networks can be accomplished.

If the complexity can be mastered there are few obstacles on the road to a digital revolution. It will be possible to architect efficient information and energy flows and the experience of transportation will never be the same again.

Keywords X-by-wire, Automotive, Embedded systems, System integration, Architecture, Industry trends

Ola Larses Modern Automotive Electronics from an OEM perspective Contents

Contents

1 INTRODUCTION............................................................................................................ 7 1.1 THE AUTOMOTIVE INDUSTRY....................................................................................... 7

2 APPLICATIONS OF MODERN AUTOMOTIVE ELECTRONICS......................... 9 2.1 BUSINESS DIMENSIONS OF APPLICATIONS.................................................................... 9

2.1.1 Target of services ............................................................................................... 9 2.1.2 Timing of services............................................................................................. 11

2.2 CLASSES OF APPLICATIONS........................................................................................ 11 2.2.1 Environmental/Economy .................................................................................. 12 2.2.2 External coordination ...................................................................................... 12 2.2.3 Safety ................................................................................................................ 12 2.2.4 Handling/Vehicle dynamics.............................................................................. 13 2.2.5 Navigation/Driver support ............................................................................... 13 2.2.6 Communication ................................................................................................ 13 2.2.7 Infotainment ..................................................................................................... 13

2.3 TECHNOLOGY DIMENSIONS OF APPLICATIONS ........................................................... 14 2.3.1 Connectivity of services.................................................................................... 14 2.3.2 Criticality of services ....................................................................................... 15

2.4 RELATING BUSINESS AND TECHNOLOGY.................................................................... 16 2.4.1 The context of applications .............................................................................. 16 2.4.2 Relationships between properties..................................................................... 18

2.5 REQUIREMENTS AND OEM FOCUS............................................................................. 19 2.5.1 What are the challenges? Where should efforts go?........................................ 20

3 CHALLENGES AND TECHNICAL SOLUTIONS................................................... 23 3.1 ENABLING CONNECTIVITY BY NETWORKING ............................................................. 23

3.1.1 In vehicle communication standards................................................................ 23 3.1.2 Telematic solutions........................................................................................... 25 3.1.3 Portable or embedded connectivity.................................................................. 25

3.2 ENDORSING DEPENDABILITY IN DRIVE-BY-WIRE SYSTEMS ........................................ 26 3.2.1 Terminology and concepts ............................................................................... 26 3.2.2 Why by-wire?.................................................................................................... 27 3.2.3 Requirements on cost and dependability.......................................................... 28 3.2.4 Drive-by-wire case studies and prototypes ...................................................... 31

3.3 SYSTEM ARCHITECTURE TRENDS............................................................................... 37 3.3.1 Topologies, ECUs and three levels of concerns............................................... 38 3.3.2 Distribution of control in cluster networks ...................................................... 39 3.3.3 Software and functional architectures ............................................................. 41 3.3.4 Future dominating industry standards............................................................. 43

4 ENABLING TECHNOLOGIES AND RELATED ISSUES ...................................... 45 4.1 OPEN STANDARDS ..................................................................................................... 45 4.2 POWER/ENERGY MANAGEMENT ................................................................................ 46

5 CONCLUSIONS............................................................................................................. 47

3 (59)


A THE SCANIA SITUATION.......................................................................................... 48 A.1 EXISTING BY-WIRE SYSTEMS ..................................................................................... 48 A.2 SYSTEM ARCHITECTURE ............................................................................................ 49

A.2.1 System design heuristics................................................................................... 50 A.3 SOFTWARE DESIGN METHODOLOGY........................................................................... 50 A.4 POSSIBILITIES AND PROBLEMS WITH THE CURRENT ARCHITECTURE .......................... 51

A.4.1 Functional architecture.................................................................................... 51 A.4.2 Network topology ............................................................................................. 52 A.4.3 Communication protocols ................................................................................ 52 A.4.4 Software............................................................................................................ 53

A.5 CONCLUSIONS ........................................................................................................... 54

REFERENCES....................................................................................................................... 55 ACKNOWLEDGEMENTS.......................................................................................................... 59

Figures FIGURE 1 - APPLICATION FRAMEWORK .................................................................................................................... 9 FIGURE 2 - TARGET FOR SERVICES ......................................................................................................................... 10 FIGURE 3 CLASSES OF APPLICATIONS.................................................................................................................. 12 FIGURE 4 - CONNECTIVITY RANGE......................................................................................................................... 15 FIGURE 5 - THE CONTEXT OF AUTOMOTIVE ELECTRONICS APPLICATIONS ............................................................. 17 FIGURE 6 - THE REDEFINED ROLE OF THE OEM ..................................................................................................... 18 FIGURE 7 - DIMENSIONS OF AUTOMOTIVE ELECTRONICS APPLICATION ................................................................ 20 FIGURE 8 - BY-WIRE TERMINOLOGY ...................................................................................................................... 27 FIGURE 9 - THE SIRIUS CAR.................................................................................................................................... 31 FIGURE 10 - THE RENAULT ELLYPSE ..................................................................................................................... 32 FIGURE 11 - THE FILO CAR..................................................................................................................................... 32 FIGURE 12 - THE NOVANTA CAR............................................................................................................................ 32 FIGURE 13 - THE AUTONOMY CONCEPT ................................................................................................................. 33 FIGURE 14 - THE HY-WIRE CAR............................................................................................................................. 33 FIGURE 15 - THE MERCEDES BENZ F400 CARVING ............................................................................................... 34 FIGURE 16 - POSSIBILITIES AND CHALLENGES FOR BY-WIRE TECHNOLOGY ........................................................... 37 FIGURE 17 - SYSTEM DESIGN LEVELS (REILHAC & BAVOUX 2002)........................................................................ 39 FIGURE 18 - ARCHITECTURE OPTIONS.................................................................................................................... 40 FIGURE 19 - LAYERING OF FUNCTIONALITY (BASED ON STEINER & SCHMIDT 2001) ............................................. 41 FIGURE 20 SCANIA ECU TOPOLOGY ................................................................................................................... 49 Tables TABLE 1- CRITICALITY RELATIONSHIPS ................................................................................................................. 18 TABLE 2- CONNECTIVITY RELATIONSHIPS ............................................................................................................. 19 TABLE 3 - COMPARISON OF GENERAL COMMUNICATION PROTOCOL CHARACTERISTICS ........................................ 24 TABLE 4 - TELEMATIC SOLUTIONS ......................................................................................................................... 25 TABLE 5 - REQUIREMENTS BY APPLICATIONS ........................................................................................................ 29 TABLE 6 - DRIVE-BY-WIRE CONCEPT CARS .......................................................................................................... 31 TABLE 7 HY-WIRE CHARACTERISTICS ................................................................................................................ 33 TABLE 8 COMMERCIAL DRIVE-BY-WIRE CASES ................................................................................................. 34 TABLE 9 - DRIVE-BY-WIRE BENEFITS ..................................................................................................................... 36 TABLE 10 - DRIVE-BY-WIRE PROBLEMS ................................................................................................................. 37 TABLE 11 - SCANIA BY-WIRE SYSTEMS .................................................................................................................. 48

4 (59)


Main Entry: OEM Etymology: Original Equipment Manufacturer Date: 1968

:: One that produces complex equipment (as a computer system) from components usually bought from other manufacturers.

(Merriam-Webster's Collegiate Dictionary)

5 (59)


6 (59)

Ola Larses Modern Automotive Electronics from an OEM perspective Introduction

1 Introduction

In a modern car electronics is revolutionizing the process of transportation. This report aims at identifying areas where electronics is being used, where it might be used and what technologies are employed to facilitate the digital experience in the automotive industry. The report has an OEM perspective and focuses on business issues and technical issues where OEMs should put in an effort. The contents are inspired by presentations at the SAE conference Convergence 2002 Transportation Electronics = Process + Business + Technology held in Detroit October 2002. Another unreferenced source is knowledge gathered by the author by working at the truck manufacturer Scania in Sdertlje during 2002.

In the first section a classification framework for applications is outlined. As there are so many applications available it is important to distinguish between them to find technical obstacles and business models that are common for a group of applications. The classification framework points out some properties that can be used for characterization of automotive electronics applications and examples are given to illustrate the framework.

In the following sections, challenges and current technical solutions are discussed and some technical issues are elaborated together with current trends in how the technical challenges are addressed by truck and car manufacturers. Then, enabling technologies that can change the solution space are discussed. Finally some conclusions on the situation at Scania are given based on experiences from the work performed there by the author.

Many technical challenges are not addressed as they are deemed to be outside the scope of OEMs. The contents try to answer:

What are the application areas of electronics in the automotive industry? Where should OEMs put in an effort? What are the possibilities and challenges within the chosen areas? What enabling technologies may change the situation? What are the industry trends? What is Scania doing in this field?

1.1 The automotive industry The automotive industry is highly competitive. The companies in the industry are pressured to maintain quick responses to customer trends in a cost efficient way. Lower cost is one of the major determinants in the market. The products are produced in rather large series and each small saving that can be done in the production cost makes big money on the bottom line.

As competition is hard, good business strategies are essential. Different companies utilize different business models. A business model defines where profits are made. Some companies focus on after sales service revenues, including spare parts. Others make money by volume, maintaining good profits through selling many cars.

In this competitive market many OEMs also rely on strong branding that creates brand and customer expectations that have to be met. The branding niches the company towards a specific market segment of potential buyers. A market segment is a homogenous body of buyers with similar preferences on the product. Knowing the preferences in the segment the OEM has the possibility to modify the product to fit the needs of the target group and to focus development efforts. Closely related to the branding is the necessity to target safety issues. Road safety is a strong general public concern and safety deficiencies

7 (59)

Ola Larses Modern Automotive Electronics from an OEM perspective Introduction

in a vehicle brought to the attention of the public can be very harmful to an OEM even if the flaw is corrected. Credibility and trust are important for automotive makers.

Further, the industry is highly regulated. There is extensive legislation with limits on noise and exhaust content, but also specifications on technical solutions like requirements on redundant braking systems and technical solutions for airbag systems.

The competitive environment requires automotive players not only to do things well, but also to do the right things. This report tries to pin down some points on where to put development effort from the OEM perspective.

8 (59)

Ola Larses Modern Automotive Electronics from an OEM perspective Applications

2 Applications of modern automotive electronics

Automotive electronics applications address a wide range of market segments and business models. Each of these segments represents different classes of applications. Besides being an important factor for business and marketing strategies the division into different types of applications makes it possible to underline differences in technology needs for each application. These technology needs can also be classified. This section outlines two possible business dimensions and then discusses how these dimensions influence the technological needs within the vehicle.

BBuussiinneessss -- TTaarrggeett -- TTiimmiinngg

FFIITT TTeecchhnnoollooggyy

- CCrriittiiccaalliittyy - CCoonnnneeccttiivviittyy

AApppplliiccaattiioonnss of Automotive Electronics

Figure 1 - Application framework

A business profile is given by addressing the target and timing of the services employed by the applications. Services are the components of applications; applications include one or more services. The target of a service is the vehicle or the people in the vehicle. The timing of a service indicates when the service is used, while the car is driven or not. A business profile can be derived for an application based on the services that the application employs. A set of applications with a certain business profile needs to comply with technology requirements in the form of criticality, related to dependability, and connectivity related to communication standards and telematics. The framework is illustrated in figure 1 and is further elaborated below.

2.1 Business dimensions of applications Automotive electronics applications have a wide range of target roles. These roles are defined by the individuals relationship with the vehicle. Further, the target roles require different applications at varying points in time. Any application can be described through answering two questions: For whom (why) is it intended? (Target) When is it intended? (Timing) In order to discuss the possibilities with automotive electronics two dimensions of applications, corresponding to the two questions, are specified below: the target and timing of services.

2.1.1 Target of services The target of services tells you the role of the customer that the application aims for. Services can aim for the people in the car or the actual car. There are also some applications specifically aiming at the driver, being the link between the vehicle and the people in it. The two types of services and the three types of applications are illustrated in figure 2. The application sets are labeled under-the-hood, front-seat and back-seat illustrating their target role in the vehicle.

9 (59)


VVeehhiiccllee--cceennttrriicc sseerrvviicceess

PPeerrssoonnaall sseerrvviicceess

Under-the-hood Front-seat Back-seat applications applications applications

Figure 2 - Target for services

Front-seat Front seat applications aim at the driving experience. The focus is on the individual driving the car but only in the role of a driver, not in the role of an individual.

There exists research on how to measure the cognitive pressure on the driver. Based on the results from this research, tentative support systems are developed. The aim is to balance the cognitive load of the driver by employing different sets of applications at different times. (Pompei, Sharon et al 2002; Aragane & Tsuji 2002).

The services can include passive support to the decision making of the driver through information systems, where an obvious example is a navigation system. Active support is also possible, automating driver decisions. Some of the active support relieves the driver of mundane tasks like switching the windscreen wipers on and off in case of rain. Other active support functions, or comfort functions, can take over actual driving tasks like automated gear shifting and cruise control.

Some of the applications are vehicle-centric, as the cruise control, while others are personal services, like the navigation systems, but they all aim at the driver in the role of a driver.

Back-seat These applications are aiming for comfort activities that are not related to the actual transport. Back seat applications are there for the people riding in the car in the role of individuals. This mainly aims at passengers but also aim at the driver as an individual. Obviously, the driver might also like to listen to music while he is in the vehicle.

Other back-seat applications relates to the use of the vehicle for non-transportation functions, where an example would be the truck-driver that lives and sleeps in his vehicle while he is on a work schedule.

Much of the back-seat applications bring the consumer electronics into the vehicle. This is driven by the fact that we are spending more and more time in vehicles (DAvello & Van Bosch 2002). Multimedia-entertainment is a field that some analysts consider to be the major field for automotive electronics in the future (Schumacher et al 2002). For this field of applications availability of services is of utmost importance, entertainment should be possible to buy anywhere, at any point in time.

Some back-seat applications relate to communication needs and include use of mobile phones and mobile internet. The communication can be used both for leisure and for work issues introducing a truly mobile office.

A range of applications that combines front-seat and back-seat issues are given within the iDrive concept from BMW (Spreng 2002). In order to avoid driver overload the iDrive uses the distinction between driving and comfort applications and separates the controls for the two purposes in the drivers compartment. (Fuchs et al 2002).

Under-the-hood Under-the-hood applications can either improve the handling of the vehicle or influence issues like maintenance, economy or the environmental impact. The applications are related to control or diagnostics of the vehicle.

10 (59)


The vehicle handling applications are often referred to as drive-by-wire where electronics are used to collect and interpret the signals of the driver in order to create an actuator response as close as possible to the anticipated driver desires. An interesting extension to drive-by-wire is the possibility to change the software or parameter content while driving and by that change the characteristics of the vehicle under control. Proper control of a vehicle can improve the economy in terms of fuel-consumption and wear of components.

Electronic diagnostics can be used both during maintenance but also as a warning system if bad readings from sensors indicate mechanical, environmental or other physical hazards. The possibility to collect driving data for statistics is another obvious application.

2.1.2 Timing of services Modern vehicles are becoming used for more and more applications even outside the time span of actual transportation. It is possible to distinguish between three categories of usage timing. The user can be riding, resting or parked as described below. It is important to point out that these categories aims at the customer as user. Within the three given categories are some maintenance and upgrading contained, but there is also a fourth category of the timing of applications that can be labeled workshop that includes maintenance work that requires physical control over the vehicle.

Riding Riding is the obvious standard situation while using the vehicle for transportation. This is the traditional focus for applications and also the kind of applications that always can be utilized by the user.

Resting This category indicates that the user is in the vehicle but is not using it for transportation. Possible uses include a short stop for resting by the road, sitting in on a drive-in movie or making an overnight sleep in a truck.

Parked Applications in the parked category relates to the time when the user is not in the vehicle. These functions need to be autonomous or remotely controlled and are to some extent an unexplored issue. Current applications include alarms and anti-theft systems.

Important enabling technologies for these applications include external communication with the vehicle, an area that is expanding but has not yet become a standard issue in current products.

2.2 Classes of applications Using the business properties described it is possible to discuss a classification range of applications based on the type of services they supply. In this section seven distinct classes are defined and discussed: Environmental/Economy, External coordination, Safety, Handling, Driver support/ Navigation, Communication and Infotainment.

The classes are based on different purposes or goals of the applications. The different goals are usually related to a specific stakeholder or role and it is therefore possible to arrange the application classes along the application target range. The classes range from applications with a vehicle centric focus to pure personal services and can be placed in the range according to figure 3. The application classes are further elaborated below.

11 (59)


Environmental/Economy

VVeehhiiccllee--cceennttrriicc sseerrvviicceess

Driver Support/ Navigation Communication

PPeerrssoonnaall sseerrvviicceess

Infotainment

External coordination Safety Handling

Under-the-hood Front-seat Back-seat applications applications applications

Figure 3 Classes of applications

Some of these application classes have overlapping properties and some applications may fit into more than one class. The framework introduced in this section is not intended as a strict classification tool but instead tries to place some common classification concepts in the more general framework introduced in previous sections.

2.2.1 Environmental/Economy Environmental applications have the goal to reduce the impact on the environment from the vehicle. In parallel to this is the goal of improved lifetime economy of the vehicle. A lean process that consumes few resources is not only environmental friendly but also cheap and cost-efficient when it is running.

Environmental issues are heavily driven by legislations and regulations. This field of applications includes the use of electronics to reduce emissions, change production to more environmental friendly processes, remove hostile substances and improve energy efficiency for example. The applications are vehicle-centric under-the-hood applications and are necessary efforts due to the strict regulation of the area.

The economy aspect is more important for commercial vehicles where fuel-consumption and maintenance are important parameters.

2.2.2 External coordination External coordination applications links vehicle external objects to the vehicle and allow them to influence the performance and/or behavior of vehicle internal functions. A commonly referenced application would be convoying. In convoying on vehicle is designated the role of convoy leader and other vehicles are allowed to hook on to the convoy as followers. The operation of the first vehicle is communicated back through the rest of the convoy. This allows immediate response to, for example, braking action throughout the entire convoy. With this coordination the vehicles can be driven with a very small distance between them which improves fuel consumption but also road congestion.

Other applications could be exemplified by externally enforced speed limitation and temporary performance enhancements of the vehicle through software tuning. Within this application class does few if any applications exist today. There are many unresolved issues to deal with before vehicle systems can be fully integrated in higher level traffic management systems that coordinate and optimizes traffic flow.

2.2.3 Safety Safety applications have the goal to ensure that no harm is done to humans in or around the vehicle. The safety applications are built into the vehicle, so even if safety applications target individuals it is a set of vehicle centric services. The applications are under-the-hood or front-seat applications as they are usually deployed by the vehicle itself.

12 (59)


Safety applications are sometimes classified as active or passive applications depending on if they prevent accidents or reduce the impact of accidents. Some safety related applications also work to improve the situation after the accident like mayday signaling systems where a call-center is notified that the airbags of the vehicle have been deployed. (Butler 2002).

2.2.4 Handling/Vehicle dynamics Applications aiming at the handling and dynamics of the car are generally referred to as drive-by-wire systems. Some of these aim at improving the drivers feel for the vehicle, others aim at improving vehicle dynamics like braking range and stopping range. By-wire control applications include systems like non-locking brakes (ABS), electronic stability programs (ESP) and electronic control of combustion in engines.

In modern applications, networked collaboration between by-wire subsystems is seen as an area where vehicle control can be substantially improved. An example of improved stopping distance by networking is given by the 30 meter car, using sensors in tires, distance sensors, active suspension and brake-by-wire networked with good results (Rieth & Eberz 2002).

2.2.5 Navigation/Driver support Navigation/Driver support applications have the goal to assist the driver with tasks associated with driving the vehicle. Navigation applications have exploded from the introduction of the GPS-system. These applications are basically front-seat applications assisting the driver with information about routes and, in some systems, also information about the current traffic situation.

Driver support applications can either supply information to the driver or filter information by screening processes and refinement to a better information quality. This includes automation applications that relieve the driver of decisions. Automation is available for mundane tasks such as windscreen wiping, and also as more sophisticated cruise control systems taking control of vehicle speed. With a reasonable amount of information, a balanced cognitive load enables better decision-making from the driver. (Pompei et al 2002).

Other navigation applications are linked to the driver as a part of a commercial logistics system. These systems instruct the driver with destinations and can also sometimes help out with navigation. More advanced applications within this type are fleet management systems that coordinate the navigation of an entire fleet of vehicles.

2.2.6 Communication Communication applications have been around for a while in the shape of cellular phones and computer networks. The goal of these applications is to get and send information between individuals, which classifies them as back-seat applications. These applications are generally supplied by telecom companies and are already well developed. Integrated standalone car phones or hands-free capabilities are not new services. In Japan it is a legal requirement that a hands-free system should be used if a cellular phone is used while driving, such legislation increases the need for integrated communication solutions.

2.2.7 Infotainment The infotainment applications are back-seat services that integrate consumer electronics in the automotive environment. Cars can include video screens, game consoles and audio systems, almost anything that you can find in your home.

As infotainment in the home is becoming computer and Internet based, trends indicate that the same services can be desired in vehicles (Bock et al 2002). Paying for entertainment like on-line music sales is projected to be one of the fastest growing consumer markets over the next 5 years. This

13 (59)


development indicates a rapidly growing market for automotive infotainment applications as access and storage of information and media becomes important services (Schumacher et al 2002).

2.3 Technology dimensions of applications So far, only business aspects for functional segmentation have been considered. Why is it useful to make the above distinction in target and timing for technical aspects?

The target and timing of applications will imply requirements on technology. Understanding these requirements is essential to identify technology needs for the future. Understanding the technology needs makes it possible to develop a strategy on where to put development effort, where to collaborate and where to outsource the responsibility of development. Therefore a model of applications is useful if relationships between application properties and technical needs can be derived.

Many new applications rely on the vehicle being connected to an information infrastructure like the Internet at any time. This requires a wireless communication infrastructure like GSM or different wireless networking standards. It is necessary to be connected at any point in time. The connectivity is strongly related to the timing of applications.

Further, some of the applications relieve the driver of responsibility or meddle internally in the vehicle itself. Related to this issue is the autonomy tradeoff. This tradeoff requires strategic decisions on when to let the driver be in control and when to let the system be in control. In the avionics industry this tradeoff is well known. By introducing limits on the operator control of the system it is possible to avoid failures due to pilot mistakes but at the same time new causes for accidents are introduced. Certain modes can be unintentionally entered and correct pilot responses are then overridden by the system. One such accident occurred on 24 April 1994 when an Airbus 300-600 entered an unintended mode during landing. The pilots and the control system engaged in a struggle for control over the airplane causing the aircraft to eventually pitch up to near vertical, stalling and crashing killing 264 passengers and crew. (Olson 2001).

If any system that influences the driving of the vehicle fails the consequences can be grave. These applications are called safety-critical and can be either direct within the vehicle or indirect, distracting the driver to make mistakes. The criticality is strongly related to vehicle-centric applications.

Thus, there are two questions for the technology dimensions: Who do I need to be in contact with? (Connectivity) What happens if the system malfunctions? (Criticality) These two questions relate to the technology dimensions labeled connectivity and criticality and are further elaborated below.

2.3.1 Connectivity of services Connectivity is a measure of how widely a technical system can communicate, it ranges from closed local solutions to open systems like the internet. An illustration of the connectivity range is given in figure 4. The connectivity can be maintained to serve either the supplier (the OEM and the dealer) by connecting to the vehicle, (Millstein 2002) or the customer (the owner and user) by connecting to the outside world (Kanayama et al 2002). The connectivity to the OEM can be used for improving maintenance, diagnosis and software updates as well as getting a statistical basis for quality issues of the vehicle. The connectivity of the owner or user will allow a range of personal services similar to those that can be found in a computer or multi-media system at home.

The services in the car can be standalone or networked systems that are embedded or mobile. Combining these features it is possible to identify four different categories of connectivity for car applications: In-car, networked in-car, plug and play and global telematics as described below.

14 (59)


In-car This refers to standalone products in the car supplying specific services. The applications can be built in from the start or brought in without regard to the rest of the vehicle system. The system is local in the vehicle.

Networked in-car These applications interact with other systems in the car and are built in from the beginning when the car is manufactured. The connectivity is within the car and the in-car network defines the information access level. This is a typical car computer supplying fuel consumption, average speed and similar statistics. The system can only be used internally in the vehicle.

Plug and play The plug and play type of applications is possible to bring into the vehicle and hook in to the internal car network. The applications can be both software and hardware based. Downloading new software, like new maps in the navigation system, would be one example of a plug and play application. Another would be the use of mobile wireless devices that can be used to connect the rest of the vehicle with the outside world. The system has an external interface from the vehicle.

Telematics With global telematics applications the vehicle is always connected through an embedded wireless device. Applications in this field could be constant on-line uploading of navigation information, an integrated embedded car phone or vehicle on-line diagnosis monitored by OEMs. With the vehicle as a constantly connected entity it is possible to consider a range of applications that can be labeled vRM or vehicle relationship management (Millstein 2002).

In-Car networked In-Car Plug and play Telematics

Local Internal Global External

Figure 4 - Connectivity range

2.3.2 Criticality of services Any application can be very important for the driving of the vehicle or it can only be a minor comfort function. These two types are very different and require completely different technical solutions. The severity of a hazard that is derived from a malfunction is labeled criticality. The criticality of services is closely linked to the type of application.

The criticality of automotive applications is defined by MISRA (The Motor Industry Research Association) to contain five levels based on categories of controllability. The categories are defined as follows (MISRA, 2001a):

Uncontrollable: This relates to failures whose effects are not controllable by the vehicle occupants, and which are most likely to lead to extremely severe outcomes. The outcome cannot be influenced by human response. Difficult to control: This relates to failures whose effects are not normally controllable by the vehicle occupants but could, under favourable circumstances, be influenced by a mature human response. They are likely to lead to very severe outcomes.

15 (59)


Debilitating: This relates to failures whose effects are usually controllable by a sensible human response and, whilst there is a reduction in safety margin, can usually be expected to lead to outcomes that are at worst severe. Distracting: This relates to failures which produce operational limitations, but a normal human response will limit the outcome to no worse than minor. Nuisance only: This relates to failures where safety is not normally considered to be affected, and where customer satisfaction is the main consideration.

The different levels of criticality or controllability render different requirements on the further development of the system. Each level of criticality corresponds to an integrity level that needs to be met by requirements in a variety of subsections in the MISRA guidelines. Subsections include: Specification and design, languages and compilers, testing etc.

Integrity is defined by MISRA as the degree to which that system is free from impairment based on the Collins Paperback English Dictionary definition: freedom from impairment or the quality of being unimpaired. An unimpaired system is defined as being able to perform its required functions, in the desired manner, under all relevant conditions, and on the occasions when it is required to perform. (MISRA, 2001b).

Alternative, more narrow, definitions of the concept integrity can be found. One is given by Laprie (1992) who defines integrity accordingly: Non-occurrence of improper alterations of information leads to integrity.

To avoid a mix-up of concepts the latter definition of integrity is allowed to hold while the wider integrity concept, concerning a response to criticality, will be replaced with the concept of dependability throughout this report. Dependability is defined accordingly:

Dependability. Dependability is a property of a system that justifies placing ones reliance on it. (Storey 1996).

Similar standards for hazard analysis and other safety guidelines exist in several variants. A general safety standard is the IEC 61508, other well known standards include the US military standard MIL-STD-882D (Amberkar et al 2000), the British military standard MoD 00-54/55/56 and the avionics standard DO-178B. A common factor in safety standards is that they prescribe ways to quantify criticality and probability of hazards.

2.4 Relating business and technology As stated before, an application model is only useful if relationships between application properties and technical needs can be derived. It has also been stated that the connectivity is strongly related to the timing of applications and the criticality is strongly related to vehicle-centric applications. But this is not the entire truth. This section elaborates on the relationships between business and technical properties.

2.4.1 The context of applications Before the actual relationships are examined it can be useful to place the model in a context. In this context we identify the players in the business and how they interact. The contextual model is illustrated in figure 5.

The traditional relationship is between the owner and the OEM through the car. The OEM supplies the service of transportation through the vehicle. By further development vehicle related service providers have created services like emergency assistance, insurance and maintenance programs targeted at the vehicle owner.

16 (59)


In parallel to this the Internet has evolved with communication suppliers and service providers (sometimes referred to as content providers) serving customers with information services in their homes or at work.

Now, concurrent with the evolution of mobile Internet, vehicles are adopting computer technology enabling Internet service providers to enter the vehicle as an access point. At the same time the content of vehicle related services can be improved.

The wish to have information at your hands at any time and the interaction over the Internet is increasing, at the same time the time spent in cars is increasing. These and other trends point to the desire to have the same personal services both in and out of the vehicle (Bock et al 2002).

The CommunicationSupplier

The OEMThe Service ProviderThe Vehicle relatedService Provider

'The Car'

The Individual Customer

Figure 5 - The Context of automotive electronics applications

This means that if the customers requirements are met, the role of the car and the OEM will be changing. The car will be more functional supplying not only transportation but also information and media services. The role of the OEM will be broadened to an extended systems integrator with new business relationships. (McElroy & Goldstein 2002, Lhamon 2002).

The communication supplier will be an integrated supplier to the OEM and some of the service providers will be more closely collaborating with the OEM. The current role of OEMs as systems integrators will be raised to a higher level. It is probable that OEMs need to depend even more on their suppliers for module integration and component R&D while their own role will be to compose a

17 (59)


product with a well-defined functional identity. (Lhamon 2002). The redefined role of the OEM is illustrated in figure 6.

The System Integrating OEM

The Service ProviderThe Vehicle relatedService Provider

'The Functional Car'

The OEMSuppliers

The CommunicationSupplier

Figure 6 - The redefined role of the OEM

2.4.2 Relationships between properties The relationships from business properties to criticality are rather straightforward to define and understand. The more related to the actual driving an application is the more critical it is.

A high criticality is only applicable for an application with riding timing, resting is less critical and parking is probably not critical at all. The criticality is obviously highest for under-the-hood target applications, while back-seat applications are not critical. Front-seat applications may or may not be critical depending on the actual application. This reasoning confines safety-critical applications to front-seat and under-the-hood applications during riding and relieves other applications of criticality. The relationships are illustrated in table 1.

Criticality Riding Resting Parking Under-the-hood High Medium Low Front-seat Medium Low Low Back-seat Low Low Low

Table 1- Criticality relationships

18 (59)


Connectivity relationships are a bit harder to define. One important dimension of connectivity is found in the basic notion that communication can go both ways. Either it is the occupants in the vehicle or the vehicle itself that want information from the outside, or it is the outside that is collecting information from the vehicle. This implies that there are different requirements on connectivity depending on what communication direction is being studied.

To start with personal services and communication into the car you find front-seat and back-seat applications. The back-seat applications have a strong interest in external connectivity, primarily while they are in the car. If the services follow the pattern from the Internet the requirements would be higher on download as more data is generally downloaded than uploaded. Interactive downloads can be necessary while driving and resting. When the vehicle is parked it is possible that back-seat customers would like to download and prepare the vehicle for an upcoming ride utilizing bulk downloads. Alternate applications might include communication with the vehicles alarm system or climate system, requesting a heated car in the morning. Thus, the possibility to download would be requested during any timing, interactively while driving and resting, and as bulk transmission while parked.

For front-seat applications the requirements are similar but it is probable that less data need to be transmitted. Navigation systems are one example that classifies in this category of personal services, communicating traffic reports and the position of the vehicle.

The vehicle-centric diagnostic applications would probably upload more from the vehicle than download but the required bandwidth would probably be low. Applications that are dynamically changing control parameters will require very little download capacity and diagnostic applications can be efficiently screened and packaged within the vehicle.

Connectivity Riding Resting Parking Under-the-hood Internal Internal Internal Front-seat Internal/External Internal/External Internal/External

Back-seat Broad External/Global Broad

External/Global Broad

External/Global Table 2- Connectivity relationships

This means that under-the hood applications have lesser demands for external connectivity, while back-seat applications require high external bandwidth, especially for downloading. The relationships are illustrated in table 2. It would be possible to argue that external coordination applications may require external communication for under-the-hood applications. This is true, but these applications are not yet broadly accepted and there will be several investigations of safety issues before these systems are introduced. Thus, these applications do not influence the connectivity. Further, the special timing case of workshop timing is left out in the table. Maintenance requires an external diagnostic interface but this interface can be seen as system internal as the OEM supplies the workshop with the necessary tools for maintenance.

2.5 Requirements and OEM focus With a full background on applications and their characteristics, as summarized in figure 7, it is possible to discuss how different applications influence the development efforts of OEMs and what the challenges are; in this section these two questions are addressed.

19 (59)


Applications of Automotive Electronicsss

SafetyInfotainment

Handling (X-by-wire)EnvironmentNavigation

Communication

Business - Timing - Target

Technology - Connectivity - Criticality

Vehicle-centricservices

Personalservices

Under-the-hoodapplications

Front-seatapplications

Back-seatapplications

Outside-CarParked

In-CarResting

Riding

Figure 7 - Dimensions of Automotive Electronics Application

2.5.1 What are the challenges? Where should efforts go? Based on the description of applications and the deployment of development efforts, OEMs are facing a variety of challenges. Some challenges are collaborative and require good relationships with relevant partners, other challenges are internal and technical. The collaborative challenges may require new forms of organization of the product development organization and new forms of relationships between companies. These organizational issues are however outside the scope of this report.

With the basic understanding that there are applications aiming at people or the vehicle, while riding or not, it is possible to classify a set of market segments for automotive electronics applications. The segmentation of applications has traditionally been based on a differentiation of riding applications driving the criticality aspects of development. New innovations in the direction of vehicle relationship management and a higher focus on customer value in back-seat applications may change this focus to issues around connectivity.

Developing for systems with a high criticality implying high requirements on dependability is an activity that swallows a lot of development resources. With the assumption that the core competence of OEMs is vehicle centric, it is easily concluded that back-seat applications should be enabled but not developed by traditional OEMs. Back-seat applications can be regarded as any consumer electronic and is not specific for automotive applications. Thus, this development must be achieved in collaboration with partners form other industries. This means that infotainment systems, communication and navigation should be sublet to suppliers and only integrated in the final vehicle. Service providers that aim at you as an individual generally supply the back-seat applications, and they only use the vehicle as a conduit for their service.

Bringing the functionality of applications together in the vehicle is another issue. With a fast growing number of functions and sensors the management of these is very important. System architecting and integration is, and will increasingly be, one of the major challenges for OEMs and this requires that methods are developed and used that can encompass any kind of system integration. Tools for communication between different development teams, both within the company and outside, are essential for this purpose. Open standards are an important part of this work that will allow a variety of suppliers outside the control of the OEM to provide subsystems to the vehicle (Coelingh et al 2002). High level modeling will also be essential both for communication of design decisions and also for the development of correct specifications. The MISRA guidelines require the use of formal methods for safety-critical applications with controllability Uncontrollable or Difficult to control (MISRA 2001).

20 (59)


Model based design and component based design are considered in research projects as methods to improve integration management.

Based on the core competence and the discussion above, the development efforts of OEMs should focus on safety, handling and economy/environmental issues on a system integrating level. Government drives the environmental requirements while economy, handling and safety are consumer driven.

External connectivity should be developed in collaboration with other partners that can supply a wireless ether. The external connectivity must be enabled in order to support in-vehicle Traffic control, Communication and Infotainment supplied by other service providers. The OEM should focus on defining the interfaces that enables services in the vehicle. (DAvello & Van Bosch 2002). An important issue in this process is to clearly define the borders of development for the OEM. If too much of applications are developed in-house not only development resources are wasted, but it will also inhibit some suppliers to integrate their services into the vehicle. On the other hand if some interfaces are underdeveloped it will be impossible for other service providers to integrate their products.

One of the major collaborative challenges is derived from this problem. The communication problem for integration as mentioned earlier is even more emphasized when dealing with external organizations. One factor to work with within this problem is the organizational issue. Suppliers have been integrated in production through just-in-time production to integrated supply and the most radical arrangement: modular consortia, where the suppliers co-invest in a production facility (Collins et al 1997). Similar transformations can be expected for the design organization, this is not further discussed here. Another part of the solution is to use open specifications of interfaces in order to allow the integration of supplier subsystems, consumer electronics and Internet based services in the vehicle (Wrtenberger 2002). A well-designed open standard will also support cost-efficient development relieving the OEMs from some of the technology issues and adding them to the supplier potential.

Thus the challenge of OEMs can be summarized in a twofold statement. OEMs will have to develop and integrate electronic systems with appropriate dependability to meet high criticality, and also enable connectivity for other service providers to supply advanced applications. One challenge is internal integration and the other is external integration; technology and suppliers of technology exist but the OEMs must deliver the integration plan.

21 (59)


22 (59)

Ola Larses Modern Automotive Electronics from an OEM perspective Challenges and solutions

3 Challenges and technical solutions

This section will elaborate on earlier identified issues and look into more detail on some of the related technical aspects. The challenge of OEMs has been summarized as to develop and integrate electronic systems with high criticality, internal integration, and also to enable connectivity for other service providers to supply advanced applications, external integration.

External integration with service providers requires connectivity and defined communication standards. The connectivity is also an important part for the internal integration but internal issues also require that the system dependability, or freedom from impairment, can be assured. The two issues of connectivity and dependability will be addressed in two separate sections below.

Possible solutions for connectivity are the target for the first section. Alternative technologies and current standards are accounted for in this part. The development and integration of the high criticality systems require some deepened discussion on by-wire systems and this is the target of the second section.

Technologies that are in the hands of content and infrastructure providers are not addressed. Typical areas where OEMs should not enter the technical scene but rely on suppliers include TFT-screens, DVD-players and hand-held computers as obvious examples. What is an important issue is to define the border. Interfaces towards consumer products should be defined and the role of the OEM and suppliers should be clarified. Many of these answers lie in the connectivity and will not be elaborated beyond the connectivity section in this work.

OEM Challenges External Integration Target: Service providers Major issue: Connectivity Second issue: Dependability Internal Integration Target: Suppliers Major issue: Dependability Second issue: Connectivity

3.1 Enabling connectivity by networking There are services that can be performed local in the car and other services that require short interaction with specific connection points, and still others that need to maintain global connectivity at any point in time. All of these applications rely on connectivity enabled by integrated network architectures.

Different buses and protocols for safety-critical applications have been thoroughly evaluated and compared (Rushby 2001). To be of commercial value networking is based on widely spread standards based on standard external interfaces. Standardization of communication is an essential issue that allows further modular development by suppliers (Coelingh et al 2002). This modular development is necessary for efficiently exploiting development resources in the automotive industry. (Malhotra 2002; McElroy & Goldstein 2002). Because of the commercial issues it is valuable to know current industry standards and future trends as well as the details of the alternatives. This section focuses on these standards and trends. Technical issues on how to create an optimal solution are not considered here.

3.1.1 In vehicle communication standards Many different communication protocols have been proposed for vehicular purposes. It is a general notion that different protocols will be used for different purposes. The vehicle will contain different networks with different requirements connected through gateways. The cheapest solution meeting the requirements for a specific network will be used. Using different subnets is a natural path in order to

23 (59)


achieve partitioning and separate concerns. A problem with different protocols is the need to support different protocols and to achieve gateway functionality, therefore is it important that all the protocols are standards that are cost-efficient. (Emaus 2000)

Society of Automotive Engineers (SAE) has a categorization of bus protocols into class A, B and C. Where class A is used for low-end general purpose communication and class C is used for safety-related real-time systems. Another four classes have been suggested to include buses in the categories of diagnostics, safety, mobile media (low speed, high speed and wireless) and x-by wire. The differentiating dimension between categories is the choice between low cost and dependability and there are a variety of protocols available in any category. (Lupini 2001; Quigley et al 2001). There is a set of automotive standards that have been and are developing implicitly related to these classes, the characteristics of the standards are given in table 3: (Lupini 2001; Teepe et al 2002) Transmission media Bit Rate Cost Max bus length Max nodes CAN J-1939 Twisted pair 250 kb/s Medium 40 m 30/10 CAN J-1850 Twisted pair 125 kb/s Low 35 m 32 CAN 2.0B Twisted pair 1 Mb/s Medium 40 m 32 LIN Single wire 20 kb/s Low 40 m 16 Flexray Optical/Wire 10Mb/s ? ? ? TTP Optical/Wire 5-25Mb/s ? ? 64/256 Firewire Shielded twisted pair 98-393 Mb/s Medium 72 m 16 MOST Optical 25Mb/s High Infinite 24

Table 3 - Comparison of general communication protocol characteristics

CAN and J-1939 The most established of these standards is probably the controller area network (CAN) that has been used in cars since the early 90s when it was first introduced by Mercedes. CAN support a set of higher-level protocols, like J-1939 and Volcano for automotive control, where J-1939 is the truck and bus standard, and J-1850 for diagnostics. The protocol can also run at different speeds, 250 kb/s in J1939, to a maximum of 1 Mb/s.

LIN The LIN-bus is a low speed serial communication bus for low-end applications. It belongs to the SAE class A buses and is currently the standard bus in this class. It is usually used for simple switches, door electronics, seat controls and similar applications.

Flexray vs. TTP The protocol for safety critical automotive networks in the x-by-wire class has been a highly debated issue. Much of the discussion is focused on the approaches to scheduling, but issues on necessary services in the protocol are also debated. The scheduling question is if it is necessary to go from priority-based systems (like CAN) to time-triggered systems (like TTP). Another alternative would be to add features to CAN and create a time triggered CAN (TTCAN). (Koopman 2002). Currently it seems that a hybrid solution, Flexray, will be the favored choice of the industry.

MOST vs. Firewire MOST is a standardization project in the high-speed mobile media class for multimedia applications with a transfer rate at 25Mbit/s. MOST is currently competing with the Firewire (IEEE1394) standard in this class.

Within the SAE safety class (not the SAE C-class), intended for airbag and similar applications, there are still no natural standard and many buses are proprietary (Teepe et al 2002). The standards for wireless mobile media are treated in the section of telematics.

24 (59)


3.1.2 Telematic solutions Telematics originally referred to the broad industry concerning the use of computers and telecommunication systems together. Today, the term has evolved to refer to wireless automotive applications including GPS and general telecommunication functions that originate or end inside the vehicle. (Webopedia 2003). Telematics is a combination of communication technologies, in-car information systems and in-car computing. Ranging from hands-free functionality to dynamic navigation and location based services. (Ender 2002)

There are several possibilities to achieve wireless communication in vehicles. One distinction is between wide area networks (WAN), generally implemented by cellular networks, and wireless local area networks (WLAN), commonly implemented by the standard IEEE 802.11b. There are also personal area networks (PAN) for short-range communication that can be considered to be similar to WLANs for some applications. Bluetooth belongs to the PAN category. (DAvello & Van Bosch 2002).

Another category that only achieves one-way data transfer is broadcast distribution systems (BDS) similar to the traditional car radio. The BDS systems are using digital transmission and both terrestrial and satellite solutions. The different types of wireless solutions and common implementations are given in table 4. (DeVries et al 2002).

Acronym Name Implementations WAN Wide Area Network GSM (Global System for Mobile-communications)

CDMA (Code Division Multiple Access) GPRS (General Packet Radio Service) UMTS (3G) (Universal Mobile Telecommunications System)

WLAN Wireless Local Area Network

IEEE 802.11x HiperLan

PAN Personal Area Network

Bluetooth IEEE 802.15.4

BDS Broadcast Distribution Systems

SDARS (Satellite Digital Audio Radio Service) DAB (Eureka/147 Digital Audio Broadcasting) IBOC (In-Band On-Channel

Table 4 - Telematic solutions

Some applications are global and are utilized wherever the vehicle is and thus require WAN or possibly BDS solutions. Other applications are local, only applicable for a specific geographical region or place, and these may benefit from solutions with WLAN or PAN. Today connectivity is usually solved through cellular communication but in response to the different needs, mobile gateways with a combination of cell phones and WLAN technologies are seen as a possible solution (DAvello & Van Bosch 2002; Kanayama et al 2002).

The different available technical solutions are seen as working well for the communication purpose, the question is how to integrate the solutions into the vehicle. In this integration process there are still a set of issues to solve.

The technologies are ready for the applications, but the applications may not be ready for the technologies. (DeVries et al 2002).

3.1.3 Portable or embedded connectivity As telematics of today are based on cellular phones the approach for integration of this component becomes a central issue. The question is if the phone, or cellular device, should be embedded in the vehicle, portable or a combination of the two. (DAvello & Van Bosch 2002).

25 (59)


Embedded devices are closely linked to the vehicle while portable devices are closely linked to an individual. Back-seat applications only use the car as conduit. The requirements on these personal services suggest that the cellular devices should be portable. Vehicle-centric applications on the other hand, that use the car as an end, would suggest embedded connectivity. Typical vehicle centric services include safety and security like emergency services and stolen vehicle tracking.

Another argument for non-embedded devices is the problem with upgradeability. Phones, like other consumer electronics, have development cycles of months before a new product arrives. Vehicles have cycles of years. Embedding a specific device might mean that the cellular device is hopelessly outdated when the vehicle hits the market. Using connectivity through technologies like Bluetooth allows the consumer to choose the latest phone technology and integrate it with the car. (DAvello & Van Bosch 2002).

Using both approaches is a third possibility that is more expensive but enables more services and more reliable services. It all comes down to the integration problem of choosing the right composition of technologies. There are several available choices and they are all working.

3.2 Endorsing dependability in drive-by-wire systems Vehicle-centric services have been classified as a priority for OEMs. They have also been classified as safety-critical. This section describes the vehicle-centric services known as drive-by-wire and the available strategies to improve the dependability as required. The subject is discussed in the context of other by-wire systems.

By-wire is a general term for the use of electronic control in any technical system. This section suggests a systematic approach to terminology and related concepts. Different requirements on different by-wire applications are surveyed and discussed. Automotive applications are covered in more detail with a set of associated benefits together with some identified problems that need to be addressed before the introduction of full drive-by-wire systems will be possible.

3.2.1 Terminology and concepts The terminology of by-wire systems has developed organically as new areas of coverage have been identified. By-wire concepts regard control systems and this section suggests a structured approach to the terminology. The by-wire terminology can principally be applied on any control system and in any area of application.

First a distinction between by-wire control systems and full by-wire systems need to be made. In a by-wire control system (BWC) some stage of the information transfer is performed through digital communication and digital decision making, not only analog signals and filtering is used. It is generally assumed that the information or control signals are digitally communicated by an embedded control system. The embedded control system comprises of a set of electronic control units (ECU) that are interconnected in a local network. In a full by-wire system (FBW) all the information is digital and also the power is transferred electrically by the use of electrical motors and electromechanical actuators. Using the terminology is it possible to state that a full by-wire system is a by-wire control system with electromechanical actuation.

A widely and rather informally used term is x-by-wire. X-by-wire is a general term that contains any application with by-wire functionality where x is a referral to the actual application. The terminology refers to the application scope of the system and can be arranged hierarchically as shown in figure 8. For example, the term fly-by-wire corresponds to applications in avionics and drive-by-wire covers automotive applications. Within these categories further refinement is possible by naming specific functions like brake-by-wire and steer-by-wire.

26 (59)


Figure 8 - By-wire terminology

X-by-wire system by-wire control -BWC full by-wire -FBW

Throttle-by-wire Brake-by-wire Steer-by-wire Clutch-by-wire Gearshift-by-wire Suspension-by-wire -by-wire

Drive-by-wire Fly-by-wire Manufacturing-by-wire -by-wire

Application specific Industry specific General terms

All the different by-wire classes can obviously be of the type control system or full system, thus rendering the expression variants brake-by-wire control system and full brake-by-wire system. In a brake-by-wire control system is the information transfer from the brake pedal to the breaking actuator handled electronically but hydraulic or pneumatic actuators, probably with electronically controlled valves, perform the actuation. If the actuators are replaced with electrical motors a full brake-by-wire system is created.

3.2.2 Why by-wire? When a shift in technology is to take place there are some initial efforts that are necessary to make the shift. To overcome these initial obstacles there must be a promise of improvement and return on investment. What makes Drive-By-Wire a winning technology?

The answer is given by a range of arguments. First, electronic control gives benefits in the implementation of more advanced and exact control algorithms at the ECU level. Further, it becomes easier to allow subsystems to work together by information exchange in networks. And third, full by-wire makes it possible to improve the systems used for distributing power to actuators.

Control unit level benefits Using high-speed electronic braking control, improvements can be made for known difficult situations. The benefits of electronic control for braking have been used in the heavy truck industry for years in order to improve the reaction time of the system. The electric signal is much faster than the pneumatic signal used in older vehicles. The reaction time can also be improved by using brake assist that reacts by preparing braking when the foot leaves the throttle pedal. It is also possible to improve the brake force distribution on the tires enabling more advanced ESP-functionality (Stoll 2001).

In a passenger car, a comparison was made between a hydraulic system with a brake response of 200 milliseconds per G-force (ms/G), and an electronic system that was able to give a response of 50 ms/G. Using electronic actuators it was possible to reduce the braking distance at 100km/h by 2 meters, from 42 to just below 40 meters. The two systems were also compared in the situation with a rapid change in friction coefficient of the driving surface while braking. The electronic system showed superior performance also in this case. (Yokohama et al 2002).

System level networking benefits The networking aspect of by-wire systems allows new control functions based on information from separate parts of the vehicle. One implementation that shows how networking can improve performance is the improved braking performance of the 30m car. A networked combination of sensors in tires, distance sensors, active suspension allows for a braking distance of 30.18m at a speed of 100 kph, approximately 8m better that a reference production vehicle. Using the technology it was also possible to reduce reaction time and braking build-up and thus improving the entire stopping distance. (Rieth & Eberz 2002)

27 (59)


By-wire control or Full by-wire? An important point to make is that a transition to full by-wire technology is necessary for the technology to be cost efficient. Using expensive mechanical/hydraulic backup is not a feasible option for cost-efficient manufacturing (X-by-wire 1998 p56). The potential economical benefits of a full by-wire system compared to a by-wire control system are enormous. A problem is that it will take a long time to achieve end-user acceptance allowing the removal of backup mechanical and hydraulic components. Due to the acceptance difficulties, a reasonable development is that drive-by-wire systems are first introduced with current solutions as a backup. In the next stage the mechanical and hydraulic systems are slowly phased out one-by-one, allowing users to get aquatinted with the thought of by-wire systems. (Scobie et al 2000, Harter et al 2000).

Going over to a full by-wire system does not only remove hydraulics and pneumatics, it also adds a lot of energy and power consuming electrical devices. It is a common notion that the voltage in vehicles need to be increased. A transition to full by-wire at least requires the introduction of 42V electrical system, it is also recognized that this might not be enough. The reason for the need to increase voltage comes from the increased power consumption and loads. An increase in voltage decreases current, copper cost, wire dimensions and weight. (Frank 2002).

3.2.3 Requirements on cost and dependability The introduction of by-wire systems have many benefits but also drawbacks. Cost and safety are two areas that have been pointed out as potential problem areas in the automotive industry (Feick et al 2000). These, and similar, uncertainties have different impact in different by-wire application areas and give differences in the requirements on by-wire systems. That is, the requirements of manufacture-by-wire and fly-by-wire are significantly different due to inherent properties of the systems. These inherent properties can be described in three dimensions: The criticality or consequence of failures, the sensitivity to frequency of failure in operations and the cost sensitivity of an application, influences requirements as will be discussed in this section.

Criticality Manufacturing systems can avoid safety aspects by utilizing fail-safe modes. In a fail-safe mode the system is allowed to fail without any risk for damage. By this are costs from verification limited by accepting some downtime when new machinery is introduced, actually using the machinery in the designated process does some of the testing. When by-wire control takes the step into freely moving and safety-critical machinery the requirement on fault-free operation is significantly sharpened. There are no fail-safe modes in the avionics industry for example. This requirement increases the need for testing and verification to ensure dependability in fly-by-wire products.

In the automotive industry there are some semi fail-safe modes that can be used. It is possible for a vehicle to shut down, maintaining steering and braking until it comes to a halt, without being a danger on its own. A problem is if this happens on a heavily trafficked highway where a collision with other vehicles is probable. Vehicles on their own have fail-safe modes but they may be used in a hazardous environment that can negate the fail-safe mode.

Reliability Sensitivity to reliability problems is related to the cost associated with a stop in the system. Space and avionic applications cannot afford any stops in the process because this will terminate the entire mission. Process, manufacturing and drive by-wire applications on the other hand have the possibility to be stopped and mended still acquiring a high availability even though reliability is not perfect. This possibility relaxes the requirements for reliability somewhat, but stops are still costly.

Cost sensitivity Cost sensitivity is related to the cost added by introducing dependability increasing measures. Improving dependability is based on some kind of redundancy that brings redundant costs with it. The avionic industry with airplane and space applications are less cost sensitive than many other industries

28 (59)


and it is in these industries some of the first safety-critical by-wire systems were introduced. These fly-by-wire applications use costly triple modular redundancy. The concept of fly-by-wire has been in use in the Airbus series aircraft commercially since 1983 in the A310 model (Augustine 2000). The Airbus 320 was the first that depends entirely on by-wire control and it was certified in 1988 (Briere & Traverse 1993).

The automotive industry is very cost sensitive because of the large series and the competitive market. Anything that increases the price of an individual vehicle must be motivated by increased consumer value. If the value of a technology is lower than the cost for the technology, or if the benefits are uncertain, it will face resistance in the development process. Introducing triple modular redundancy is not a feasible solution in this industry.

Fault handling strategies Based on the sensitivity to dependability and cost different fault handling strategies are chosen. From one point of view there are three different levels of fault handling: Fail safe (FS), Fault tolerant (FT) and Fault detecting (FD) systems.

Fail-safe systems utilize a safe shutdown sequence to a previously known static safe state. Operability is not maintained in the occurrence of a failure. Fault detecting systems use an even simpler fault handling strategy, only alerting the operator when an error is detected, leaving the decision-making of the fault handling to other systems. These are common strategies at plants where process by-wire and manufacturing by-wire is used.

The most rigorous way to approach fault handling is to implement fault tolerance. Fault tolerance maintains operation even in the presence of faults. It may preserve the degree of service or go through a degeneration process known as graceful degradation, where a lessening degree of service is maintained. Fault tolerance is employed in avionics and is to some extent used in drive by-wire applications. The degree of fault tolerance in future automotive applications is still undecided.

The issues that have been discussed and the properties of different applications are summarized in table 5.

Application area Example Cost sensitivity Reliability sensitivity Criticality

Fault strategy

Space-by-wire Satellites Low High Low FT Fly-by-wire Airbus Medium High High FT Process-by-wire Nuclear Low Medium High FS Drive-by-wire Cars High Medium Medium FS/FT Manufacture-by-wire Robotics High Medium Low FD/FS

Table 5 - Requirements by applications

Necessity of fault tolerance In order to replace critical functions in the vehicle and to adhere to current legislation that demands a redundant braking system, some fault-tolerance is unavoidable. The implementation of fault-tolerance is a hot issue for discussion. The only way to implement fault-tolerance is through redundancy, and adding redundancy is a very costly thing to do. The safety, reliability and cost aspects are approached from different angles by different researchers. Even tough the implementation of fault-tolerance is not an agreed issue, the inclusion of a system that tolerates single points of error within the system with maintained critical functionality is consensus. This level of fault-tolerance is seen as necessary for the by-wire system to exceed current systems in the field of safety. (Sallee 2001, X-by-wire 1998, Scobie et al 2000, Sanfridsson et al 2000).

An interesting point to make is that it is not clearly defined what a single point of error is. It is necessary to define at what level faults and errors should be considered. Is an error defined as an error in the entire braking system, or an error in one of the brake actuators, or an error in a part of the

29 (59)


actuator? Building fault tolerance requires a fault model that describes the errors that you require to tolerate. Some authors advocate that it is only necessary to consider faults and errors at the assembled system level with application specific fault tolerance (Saltzer et al 1984), while others wants to be more thorough and use systematic fault tolerance. Systematic fault tolerance is achieved by system partitioning, followed by fault tolerant design of each subsystem and system wide integration. (Avizienis 1997).

The application specific approach can be more efficient and quick if the system works in a well known environment and is not supposed to undergo any changes in the future. The systematic fault tolerance is more tolerant to new faults introduced by system or environment changes. However, no matter what approach is used the performance always relies on the quality of the fault hypothesis employed. The fault hypothesis is a model that contains all the faults the system is designed to tolerate.

Fault-containment No matter what fault handling strategy is chosen the issue of fault-containment remains important. Fault-containment means that a fault or error that occurs locally within in a subsystem is not allowed to propagate to other subsystems. It is necessary to maintain some kind of separation boundary or firewall that contains the fault in the original region. This separation does not have to be physical, but it is also possible to have logical and temporal separation that allows fault containment (Watt 2000). For a system to be fault-tolerant the issue of fault containment becomes critical (Scobie et al 2000). If a fault is allowed to propagate a single fault can cause several faults that in turn cause errors or even system failures.

One concept that improves the possibility to implement fault-containment is fail-silent systems. A fail-silent unit ceases to function by shutting down. This means that any internal fault is contained within the unit and the fault will not propagate. On the other hand this strategy might unnecessarily close down a functional unit if not implemented properly.

A dependable implementation of communication Another interesting issue is the choice of communication protocol. Almost all of the research being done considers time triggered protocols to be superior to event triggered protocols. Discussing in terms of time-triggered and event-triggered protocols is actually a simplification of the properties of the protocols. Predictable time variation is not only derived from triggering, other factors that influence the timing behavior include scheduling policies (for execution and communication), clock synchronization and the establishment of a global time-base. (Trngren 1998). To simplify the reasoning here a distinction is made between event-triggered and time-triggered protocols.

Scobie et al (2000) concludes that the time-triggered architecture (TTA) can cope with the requirements concerning both cost and reliability. Considering this rather unanimous theoretical vote for time-triggered protocols it is interesting to see that practical implementations are prone to use the event-triggered CAN protocol. An example is the implementation of sensotronic brake control (SBC) in Mercedes SL-class cars. This is an electro-hydraulic brake-by wire system, utilizing CAN for communication (Stoll 2001). The obvious reason for this is that the event-triggered CAN network is more or less the only standard available.

The need for a time triggered solution is not because of requirements from a single function, instead it is a system level requirement enabling reliable integration of functions. Time-triggered protocols are deterministic and communication can be verified. Each application need to be separated from the others ensuring non-interference. Currently the complexity of systems can be handled by making sure that enough bandwidth is available, but increased use of software will change the requirements on the in-car network. It is probable that different applications will use different protocols as previously discussed in the section on connectivity, and safety-critical applications will use a deterministic time-triggered protocol. (Kopetz & Grnsteidl 1993).

modern automotive electronics from an oem perspective

Documents