an integrated architecture for future car generations

An Integrated Architecture for Future Car Generations

P. Peti, R. ObermaisserVienna University of Technology

Austria{php,ro}@vmars.tuwien.ac.at

F. Tagliabo, A. Marino, S. CerchioCentro Ricerche Fiat

Orbassano, Italy{fulvio.tagliabo,reti1,stefano.cerchio}@crf.it

Abstract

Depending on the physical structuring of large distrib-uted safety-critical real-time systems, one can distinguishfederated and integrated system architectures. The DE-COS architecture combines the complexity managementadvantages of federated systems with the functional inte-gration and hardware benefits of an integrated approach.This paper investigates the benefits of the DECOS inte-grated system architecture as an electronic infrastructurefor future car generations. The shift to an integrated ar-chitecture will result in quantifiable cost reductions in theareas of system hardware cost and system development.

In the paper we present a current federated Fiat carE/E architecture and discuss a possible mapping to an in-tegrated solution based on the DECOS architecture. Theproposed architecture provides a foundation for mixed-criticality integration with both safety-critical and nonsafety-critical subsystems. In particular, this architec-ture supports applications up to the highest criticalityclasses (10−9 failures per hour), thereby taking into ac-count the emerging dependability requirements of by-wirefunctionality in the automotive industry.

1. Introduction

One can distinguish two classes of systems for dis-tributed applications, namely federated and integratedsystems. In a federated system, each application sub-system has its own dedicated computer system, whilean integrated system is characterized by the integra-tion of multiple application subsystems within a singledistributed computer system. Federated systems havebeen preferred for ultra-dependable applications dueto the natural separation of application subsystems,which facilitates fault-isolation and complexity man-agement.

Integrated systems, on the other hand, promise mas-sive cost savings through the reduction of resource du-plication. In addition, integrated systems permit an

optimal interplay of application subsystems, reliabil-ity improvements with respect to wiring and connec-tors, and overcome limitations for spare componentsand redundancy management. An ideal future systemarchitecture would thus combine the complexity man-agement advantages of the federated approach, but wouldalso realize the functional integration and hardware ben-efits of an integrated system [7, p. 32]. The challengeis to devise an integrated architecture that provides aframework with generic architectural services for inte-grating multiple application subsystems within a sin-gle, distributed computer system, while retaining theerror containment and complexity management bene-fits of federated systems.

There is a steady increase in electronics in automo-tive systems in order to meet the customer’s expecta-tion of a car’s functionality. Cars are no longer simplemeans of transportation but rather need to convincecustomers with respect to design, performance, drivingbehavior, safety, infotainment, comfort, maintenance,and cost. In particular during the last decade, elec-tronic systems have resulted in tremendous improve-ments in passive and active safety, fuel efficiency, com-fort, and on-board entertainment. In combination witha “1 Function - 1 Electronic Control Unit (ECU)” de-sign philosophy that is characteristic for federated ar-chitectures, these new functionalities have led to elec-tronic systems with large numbers of ECUs and a het-erogeneity of communication networks.

However, in order to satisfy the industrial demandson performance, dependability and cost with respectto a large variety of different car platforms, the cur-rent state-of-the-art system development methodologyis heavily imposed to be reviewed, because of

• the strong competition among the carmakers;

• the requirement to continuously improve comfortfunctionality with stringent time-to-market con-straints;

• the introduction of by-wire vehicle control andthose functions introduced following normative

pressure (e.g., fuel consumptions);

• a demand of greater versatility of the vehicle, con-ceived in a new view about modularity and stan-dardization.

In particular, a low number of ECUs offers signif-icant benefits with respect to architecture complex-ity, wiring, mounting, hardware cost and many others.Thus, a reduction of the number of ECUs is of great in-terest.

It is the objective of this paper to present the DE-COS integrated architecture for dependable embeddedcontrol systems for future automotive systems. This in-tegrated architecture is based on a time-triggered corearchitecture and a set of high-level services that sup-port the execution of newly developed and legacy ap-plications across standardized technology-invariant in-terfaces. Rigorous encapsulation guarantees the inde-pendent development, seamless integration, and oper-ation without unintended mutual interference of thedifferent application subsystems. The integrated archi-tecture offers an environment to combine both safety-critical and non safety-critical subsystems within a sin-gle distributed computer system. The architecture ex-ploits the encapsulation services to guarantee that soft-ware faults cannot propagate from non safety-criticalsubsystems into subsystems of higher criticality.

In this paper, we map a present automotive in-frastructure onto the DECOS architecture and elab-orate on the respective benefits, such as independentdevelopment, the assignment of integration responsi-bility, and an optimized use of resources through ar-chitectural gateway services. In order to maximize theeconomic impact, we propose a portable architecturethat can be deployed in all segments of the car manu-facturer (segment from A to E and also for luxury cars).Thereby a reduction of cost due to the increase in vol-ume is expected. To achieve the required flexibility andportability, the architecture is be based on general pur-pose hardware and a modular software concept allow-ing to protect the intellectual property of vendors.

This paper is structured as follows. Section 2 givesan overview of the DECOS integrated architecture, pre-senting the main underlying concepts. In Section 3, wediscuss the current state-of-the-art of automotive ar-chitectures. The mapping to an integrated solution isthe focus of Section 4. The discussion presented in Sec-tion 5 evaluates the integrated architecture based onprevalent E/E automotive trends.

2. The DECOS Integrated Architecture

The DECOS architecture [13] offers a frameworkfor the development of distributed embedded real-timesystems integrating multiple Distributed Application

Subsystems (DASs) with different levels of criticalityand different requirements concerning the underlyingplatform. Structuring rules guide the designer in thedecomposition of the overall system both at a func-tional level and for the transformation to the physicallevel. In addition, the DECOS integrated architectureaims at offering to system designers generic architec-tural services, which provide a validated stable base-line for the development of applications.

2.1. Functional System Structuring

Until now, the introduction of structure and hi-erarchical relationships represents the only promis-ing approach for understanding complex systems withlarge numbers of parts and interactions between theseparts [26, chap. 8]. This insight applies to all techni-cal systems and in particular to the mastering of large,complex real-time computer systems. The complexityof a large real-time computer system can only be man-aged, if the overall system can be decomposed intonearly-independent subsystems with linking interfacesthat are precisely specified in the value and time do-main [14]. Near-independence is the ability of a sub-system to serve its purpose independently from the de-tailed structure of other subsystems, i.e. only based onthe specification of the linking interfaces of the subsys-tems.

For the provision of application services at the con-trolled object interface, the real-time computer systemis divided into a set of nearly-independent subsystems,each providing a part of the computer system’s over-all functionality. We denote such a subsystem as a Dis-tributed Application Subsystem (DAS), since the imple-mentation of the corresponding functionality will mostlikely involve multiple components that are intercon-nected by an underlying communication system. Theimplementation as a distributed system is a prerequi-site for establishing fault-tolerance by redundantly per-forming computations at separate components that failindependently. Furthermore, a distributed solution be-comes a necessity, when the resource requirements ofthe application providing the subsystem’s functional-ity exceed the available resources of a single compo-nent.

An example for a DAS in the automotive domainis the steer-by-wire subsystem. With steer-by-wire [8]the transmission of the wheel rotation to a steeringmovement of the front wheel is performed with thehelp of electronically controlled actuators at the frontaxle. The main advantages in comparison with conven-tional steering systems are improvements with respectto crashworthiness, weight, and interior design.

In analogy to the structuring of the overall system,

we further decompose each DAS into smaller unitscalled jobs. A job is the basic unit of work that em-ploys the communication system for exchanging infor-mation with other jobs, thus working towards a col-lective goal. The interface between a job and the com-munication system is denoted as a port. Depending onthe data direction, one can distinguish input ports andoutput ports. A job employs input ports for exploit-ing the services of other jobs, while output ports en-able a job to provide its own services. Every job has ac-cess to its relevant transducers, either directly via thecontrolled object interface or via a communication sys-tem with known temporal properties.

2.2. Physical System Structuring

During the development of an integrated system thefunctional elements must be mapped to the physicalbuilding blocks of the platform. These building blocksare clusters, physical networks, components and parti-tions. A cluster is a distributed computer system thatconsists of a set of components interconnected by aphysical network. A component is a self-contained com-putational element with its own hardware (processor,memory, communication interface, and interface to thecontrolled object) and software (application programs,operating system) [14], which interacts with its envi-ronment by exchanging messages across Linking In-terfaces (LIFs). The behavior of a component can bespecified in the domains of value and time. Compo-nents are the target of job allocation and provide en-capsulated execution environments denoted as parti-tions for jobs. Each partition prevents temporal inter-ference (e.g., stealing processor time) and spatial in-terference [22] (e.g., overwriting data structures) be-tween jobs. In the DECOS architecture, a componentcan host multiple partitions and host jobs that can be-long to different DASs.

2.3. Architectural Services

Generic architectural services separate the applica-tion functionality from the underlying platform tech-nology in order to facilitate reuse and reduce designcomplexity. This strategy corresponds to the conceptof platform-based design [25], which proposes the in-troduction of abstraction layers, which facilitate refine-ments into subsequent abstraction layers in the designflow.

The DECOS architectural services depicted in Fig-ure 1 are such an abstraction layer. The specificationof the architectural services hides the details of the un-derlying platform, while providing all information re-quired for ensuring the functional and meta-functional

C1 Predictable Message Transport

C2 Fault-Tolerant Clock Synchronization

C3 Strong Fault IsolationC4 Consistent Diagnosis

of Failing Nodes

Time-Triggered Architecture

Encapsulation, Virtual Networks, Diagnosis,...

JobJobJobJob JobJob JobJobJobJob

Time-Triggered Core Architecture

Hiding of implementation details from the application, thereby extending the

range of implementation choices(e.g. TTP/C, Time-Triggered Ethernet)

Figure 1. The DECOS Integrated System Archi-tecture

(dependability, timeliness) requirements in the designof a safety-critical real-time application. The architec-tural services serve as a validated stable baseline thatreduces application development efforts and facilitatesreuse, because applications build on an architecturalservice interface that can be established on top of nu-merous platform technologies.

In order to maximize the number of platforms andapplications that can be covered, the DECOS archi-tectural service interface distinguishes a minimal set ofcore services and an open-ended number of high-levelservices that build on top of the core services. Thecore services include predictable time-triggered mes-sage transport, fault tolerant clock synchronization,strong fault isolation, and consistent diagnosis of failingcomponents through a membership service. The smallnumber of core services eases a thorough validation(e.g., permitting a formal verification), which is crucialfor preventing common mode failures as all high-levelservices and consequently all applications build on thecore services. Any architecture that provides these coreservices can be used as a core architecture [23] for theDECOS integrated distributed architecture. An exam-ple of a suitable core architecture is the Time-TriggeredArchitecture (TTA) [11].

Based on the core services, the DECOS integratedarchitecture realizes high-level architectural services,which are DAS-specific and constitute the interface forthe jobs to the underlying platform. Among the high-level services are virtual network services and encap-sulation services. On top of the time-triggered physical

network, different kinds of virtual networks can be es-tablished and each type of virtual network can exhibitmultiple instantiations (see Figure 1). The encapsula-tion services ensure spatial and temporal partitioningfor virtual networks in order to obtain error contain-ment and control the visibility of exchanged messages.

3. Today’s Automotive Architectures

To give an impression of the complexity and theamount of electronics in today’s luxury cars take forexample the electronic infrastructure of a Fiat car de-picted in Figure 2. The distributed ECUs of each fed-erated cluster of the car are interconnected viacommunication networks with different protocols(e.g., Controller Area Network (CAN) [21], Local In-terconnect Network (LIN) [17]), physical layers,bandwidths (10 kbps–500kbps), and dependability re-quirements.

The Body Control cluster as well as the TelematicInfo cluster, are typically implemented via a low speedCAN bus (125kbps), while the Dynamic Vehicle Con-trol cluster is implemented via a high speed CAN bus(500kbps). The Infotelematic system also uses a highspeed CAN to exchange camera and video informa-tion. These multiple federated clusters are intercon-nected with a central gateway inside the Body Com-puter, allowing controlled data exchange between theDynamic Vehicle Control cluster and the Body Controlcluster, and access to the On-Board Diagnosis (OBD)system of each ECU. For on-board diagnosis either adedicated serial line interconnects the ECUs or the di-agnostic protocol is executed via the low speed CANnetwork.

Each of these clusters consists of nodes that are typ-ically dedicated to a single job. This is frequently re-ferred to as “1 Function - 1 ECU” design strategy.In combination with the need to adapt products toemerging trends and customer requests, manufacturesare forced to steadily increase the number of deployedECUs in order to improve the functionality of the car.For example, Fiat cars contain up to 40 ECUs. How-ever, this trend of increasing the number of ECUs iscoming to its limits, because of complexity, wiring,space and weight restrictions. For example, electricalconnections are considered to be one of the most impor-tant failure causes in automotive systems. Field datafrom automotive environments has shown that morethan 30% of electrical failures are attributed to con-nector problems [28]. With an average cost of 30-50Euros per ECU this high number of ECUs bears sig-nificant potential for cost reduction.

3.1. System Integration

During system integration significant efforts arecaused by unanticipated interactions between subsys-tems provided by different vendors. The sharing ofcommunication resources in today’s cars across dif-ferent subsystems (e.g., systems based on the CANprotocol) makes it hard to fully test the functional-ity of a subsystem in isolation as it will be integrated inthe car. As a consequence, there is the need for a com-prehensive integration test by the car manufacturerto determine possible mutual interference of sub-systems. In contrast, a system architecture withrigorous operational interface specification [14] and er-ror containment can avoid the introduction of mutualinterference during system integration. Such a tempo-rally composable architecture [12] exhibits the benefitof dramatically decreasing integration costs, be-cause the validity of test certificates from suppliers isnot invalidated during system integration.

3.2. Complexity Control

Each subsystem (e.g., engine control, brake assis-tant) possesses a functional complexity that is inherentto the application. The functional complexity of a sub-system when implemented on a target system is dra-matically increased in case the architecture does notprevent unintended architecture-induced side effects atthe communication system. Since federated systemsemploy a dedicated computer system for each subsys-tem, the complexity of the system is lower compared tothe integrated systems approach. The absence of inter-actions and dependencies between subsystems reducesthe cognitive complexity to a manageable level. In to-day’s cars we do not find a totally federated architec-ture nor an integrated one. In fact, the economic pres-sure in the automotive industry requires system design-ers to utilize the available communication resources formore than one subsystem without protecting the re-sources from mutual interference. For a deeper under-standing consider an exemplary scenario with two sub-systems. If the two subsystems share a common CANbus [21], then both subsystems must be analyzed andunderstood in order to reason about the correct be-havior of any of the two subsystems. Since the mes-sage transmissions of one subsystem can delay mes-sage transmission of the other DAS, arguments con-cerning the correct temporal behavior must be basedon an analysis of both subsystems. In a totally feder-ated system, on the other hand, unintended side effectsare ruled out, because the two subsystems are assignedto separate computer system.

Dynamic Vehicle Control

Gateway

Body Control

C -C

AN

B - CAN

Telematic Info

TelematicInfo

Televisioncapture

Camera TV

CAN for infotelematic

Body Computer

DiagnosisSerial Line

Engine Control

Automatic Gear

AdaptiveCruise Control

Parking Brake

External lighting

positioning

BreakAssistant

Clima

Door driver

side coltrol

Door passenger

side control

Instrument cluster

Passive Entry

Driver seat

Passenger seat

DiagnosisAccess for

low speed CAN

Internal mirrorand internal light

Pneumatic PressureSensor

Rain sensor

Lock siren

ProprietaryB

us

Immobilizer

GPS,G

SM

CDChanger

Wiper

Vehicle stability sensor

Angle steering sensor

Hi-FiiAmplifier

Security, Sensoring

Steering wheelsensor

Lock/UnlockSteering wheel

Drive assistant

Airbag

Trunk

Figure 2. The Electronic Infrastructure of a Fiat Car

4. An Architecture for Future Car Gen-erations

This section describes the proposed integrated ar-chitecture for future car generations. We start by dis-cussing a hybrid top-down/bottom-up design strategy,improving the currently prevalent ECU-centric devel-opment process. The decomposing during the processresults in a set of DASs. Thereafter, we elaborate onthe DASs of a hypothetical future car and its consti-tuting gateways. Finally, we show the physical struc-ture of the integrated system.

4.1. Design Flow

The design flow of automotive distributed systemscan be decomposed into three phases, the requirementanalysis, the subsystem design, and the system inte-gration phase [6] (see also Figure 3). As describedin [20, 24] an ECU-centric design process prevails in theautomotive industry. Such a bottom up process, how-ever, bears significant drawbacks such as resource du-plications, local instead of global quality-of-service op-timization, and exponential growth in terms of systemintegration costs. Furthermore, the number of the de-ployed ECUs steadily increases to satisfy recent market

trends and the customer’s demand for new functional-ity.

The DECOS architecture, by contrast, also supportsa top-down design approach. During the requirementanalysis the system integrator captures the require-ments of the overall system (i.e. the car electronics)and decomposes the system into nearly-independentsubsystems (i.e. DASs). The requirement analysis pro-vides the foundation for all later design stages. Here,the overall functionality of the system is specified andsubsystems are identified to enable an independent de-velopment of DASs. As depicted in Figure 3 the resultof this design phase is a set of DASs that comprise theelectronic infrastructure of the car.

The structuring of the overall application function-ality into DASs is guided by the following principles:

1. Functional Coherence. A DAS should provide ameaningful application service (e.g., brake-by-wireservice of a car) to its users at the controlled ob-ject interface. By associating with a DAS an appli-cation service that is relevant in the actual appli-cation context, the mental effort in understandingthe various application services is reduced. An ap-plication service can be analyzed by solely consid-ering the jobs of the DAS, the interactions to thecontrolled object and the gateways to other DASs(inter-DAS interfaces). In particular, it is not nec-

DAS

Job Job

DAS

Job Job

DAS

Job Job

DAS

Job Job

SYSTEMINTEGRATION

REQUIREMENTANALYSIS

SPECIFICATIONOF EACH DAS




SYSTEM SPECIFICATION

Functional Design

Decomposition &Detailed Design

Virtu

alGa

tewa

ys

Inte

r-D

AS

Inte

rfac

e

Virtual Gateways

Inte

r-D

AS

Inte

rfac

e

DAS DESIGN

PortsPorts Ports PortsPortsPortsPorts Ports

o Input vs. Outputo ET vs. TT




Figure 3. Design Flow

essary to possess knowledge about the internal be-havior of DASs, other than the one providing theapplication service that is of interest.

2. Common Criticality. In general, the realizationof safety-critical services is fundamentally differ-ent from the design of non safety-critical services.While the first incorporate fault-tolerance func-tionality and focus on maximum simplicity to fa-cilitate validation and certification, the latter areusually characterized by a larger amount of func-tionality and the requirement of flexibility and re-source efficiency. The integrated architecture takesthis difference into account by distinguishing be-tween safety-critical and non safety-critical DASsalong with dedicated architectural services.

3. Infrastructure Requirements. A DAS pos-sesses common requirements for the underlying in-frastructure. A single virtual network is employedfor exchanging message within the DAS. Conse-quently, common requirements (e.g., with respectto dependability, bandwidth and latency re-quirements, flexibility) are a prerequisite fordeciding on a particular virtual network pro-tocol (e.g., time-triggered or event-triggered)and a corresponding configuration (e.g., band-width).

Whenever significant differences in the above as-pects are present, such as missing functional coherenceor differences with respect to the infrastructure require-ments, a DAS is split into smaller DASs for resolvingthese mismatches.

This divide and conquer principle can only be re-alized if the dependencies between DASs are made ex-

plicit in order to avoid hidden interactions (e.g., via thecontrolled object) that may prevent a seamless systemintegration. These DASs are then assigned and inde-pendently developed by different vendors. In general,each vendor may also depend on subcontractors to de-liver the subsystem.

In order to ensure correct system integration thespecification of inter-DAS relationships is of high im-portance. Inter-DAS interfaces as indicated in Figure 3are used to specify common information within DASs(e.g., sensor information), possible interrelationshipsvia the controlled object, and meta-functional aspects.This way, resources can be shared among DASs, thusavoiding resource duplication by eliminating sensors orusing redundant sensory information to improve de-pendability.

The DAS design is typically performed by differentvendors with expert knowledge in particular applica-tion domains (e.g., infotainment, braking systems). In-dependent development of a DAS allows to adopt thebenefits of the federated systems design approach tobe incorporated into the integrated systems design ap-proach.

Finally, the system integrator needs to unify theseparately developed subsystems into the overall sys-tem. System integration unites the separately devel-oped subsystems into the overall system. An integratedsystem approach must provide solutions that reduceintegration time and efforts (and consequently reduceintegration costs). Smooth system integration is onlypossible, if the inter-DAS interfaces have been preciselyspecified and all vendors have performed implementa-tions adhering to these interface specifications. Duringsystem integrations three main tasks need to be per-formed by the system integrator: the physical alloca-tion of the jobs (of all DASs) to partitions taking de-pendability and resource constraints into account, theconfiguration of the virtual communication networks,and the realization of the virtual and physical gate-ways in order to provide emerging services.

4.2. Integrated System Structure of Car

In this subsection, we map the introduced electronicinfrastructure of today’s cars onto the DECOS inte-grated architecture. In addition, we replace state-of-theart powertrain domain functionality by by-wire sub-systems to emphasize the suitability of the proposedDECOS architecture for mixed-criticality applications(i.e. safety-critical and non safety-critical applications).We split up the existing domains (e.g., powertrain,body) into smaller DASs. Smaller DASs are a key ele-ment to achieve the DECOS goals with respect to com-

Internal Mirror and

Light

Interior DAS

Clima

DriverDoor

PassengerDoor

Driver Seat Passenger Seat Lock Alarm

Lock/UnlockSteering Wheel

Steering DAS (by-wire) Braking DAS (by-wire)

FT Steering Angle Sensor

1

FT Steering Actuator

1

Brake Assistant

ParkingBrake

BrakeLeft Front

BrakeRight Front

BrakeLeft Back

BrakeRight Back

Powertrain DAS (by-wire)

Engine Control

Automatic Gear

Adaptive Cruise

Controller 1

Vehicle Dynamics DASYawrate/

Lateral Acc.Sensor

Radar 1Camera 1

Passive Safety DAS

Airbag Driver


2


3


2


3

Yawrate/Lateral Acc.

Sensor

Radar 2Camera 2

AirbagPassenger

SideAirbag

SideAirbag

Adaptive Cruise

Controller 2

FT Pedal Sensor 1

FT Pedal Sensor 2

FT Pedal Sensor 3

Energy and Powermanagement DAS

AlternatorVoltage

Regulation

BAS

BatteryManagement

VoltageConversion

Management

Start and Stop

Function

Virtual Time-Triggered Network Virtual Time-triggered Network

Keyless Entry Trunk

Virtual Time-Triggered Network

Virtual Time-Triggered Network Virtual Time-Triggered NetworkVirtual Event-Triggered Network


Instrument Cluster

Info DAS

Telematic Info CD Changer

Navigation TV

Camera Hi-Fi Amplifier

Driver Control DASSteering Wheel

Buttons

External Lighting DAS

LightPositioning

Left

RadioDVD

LightPositioning

Right

Virtual Event-Triggered Network


Virtual Event-Triggered Network

Figure 4. The Distributed Application Subsystems of the Integrated Automotive System

plexity management, independent development and er-ror containment.

As described in Section 2.1, a DAS represents anearly-independent subsystem [26, chap. 8], becauseit can be understood independently from the detailedstructure of other DASs, i.e. only based on the specifi-cation of the jobs of the DAS and the gateways to otherDASs. The controlled export of information throughgateways enables the designer to abstract from the jobsin other DASs, considering only the link specificationof the gateways [18].

The DECOS architecture encapsulates DASs bothat the level of the communication activities (throughencapsulated virtual network services [19]) and at thelevel of the computational activities (partitions in ap-plication computers [13]). Therefore, a design fault ina DAS (e.g., a job with a babbling idiot failure [10])cannot affect the communication resources (e.g., band-width, guarantee of latencies) and computational re-sources (e.g., CPU time) available to other DASs. Nat-urally, the finer the subdivision into DASs, the more ef-fective the encapsulation through the architecture be-comes.

In a federated architecture, which assigns each DASto its own dedicated computer system, a strategy witha large number of small DASs would not be feasi-ble due to the cost resulting from increasing resourceduplication (via separate networks and ECUs). How-ever, in our proposed integrated architecture, the re-sulting larger number of DASs does not induce a largernumber of physical networks and ECUs. Each DAS isprovided as a virtual network on top of the physicaltime-triggered network of the core architecture. Simi-larly, the virtual gateways (see Section 4.3) for couplingDASs do not induce any additional ECUs and connec-tors.

Based on this line of reasoning, we introduce a finergranularity of DASs compared to the domains of to-

day’s automotive architectures (see Figure 4):

• Steering DAS. With steer-by-wire the transmis-sion of the wheel rotation to a steering move-ment of the front wheel is performed with thehelp of electronically controlled actuators at thefront axle. The main advantages in comparisonwith conventional steering systems are improve-ments with respect to crashworthiness, weight, andinterior design.

• Powertrain DAS. The functionality of this DASincludes engine control, automatic gear control,and adaptive cruise control.

• Braking DAS. The braking DAS comprises thebrake-by-wire functionality. Brake-by-wire sys-tems remedy deficiencies of conventional hy-draulic braking systems, such as aging of brak-ing fluids, difficulties in routing of pipes, andthe inconvenient feedback during ABS brak-ing. Brake-by-wire systems incorporate brakepower assist, vehicle stability enhancement con-trol, parking brake control, and tunable pedalfeel.

• Vehicle Dynamics DAS. In the vehicle dynam-ics DAS all sensory information that is relevantfor controlling the dynamics of the vehicle is cap-tured. By exporting these real-time images to theother DASs of the system the problem of resourceduplication can be significantly reduced. In addi-tion, sensor-fusion algorithms [5] can combine themeasurements of different sensors to obtain moreaccurate real-time images.

• Energy DAS. The main purpose of this DAS isthe optimization of the power distribution (elec-trical energy and power management techniques)for conserving the power available in the vehicle.

• Passive Safety DAS. The passive safety DAS in-tends to keep the passengers in the car and effec-tively decelerates the occupants in order to mini-mize harm in case of a crash.

• Driver Control DAS. In every car the instru-ments inform the driver about the current statusof the car. It is the task of this DAS to updatethe instruments according to the information pro-vided by the other DASs of the car. Furthermore,the commands of the driver derived from the but-tons on the steering wheel are processed and dis-seminated to the respective DASs.

• Interior DAS. This DAS comprises the bodyelectronics of the passenger compartment and ac-cesses fieldbus network, such as those embeddedin the doors and seats of the car. The functional-ity of this DAS includes the control of the doors(e.g., mirrors, window lifters), the seats (e.g., seatadjustment, the position memory), the climatecontrol, and the lighting of the passenger compart-ment. Furthermore, this DAS ensures that only au-thorized persons have access to the car.

• Info DAS. Car drivers are no longer satisfied withcars being simple means of transportation. To-day’s luxury cars include GPS navigation systems,DVD players and high-end audio systems. In addi-tion, voice control and hands-free speaker phonesrelieve the driver from concentrating on multime-dia devices instead of traffic.

• External Lighting DAS. The external lightingDAS controls the rear lights of the car, as well asthe position of the adaptive forward lighting.

The communication infrastructure provided to theseDASs depends on the respective criticality and regular-ity of the communication activities. Time-triggered vir-tual networks handle the communication exchanges ofall safety-critical and safety-relevant DASs. It has be-come widely accepted that safety-critical automotiveapplications employ the time-triggered control para-digm [23], because this control paradigm permits toguarantee a deterministic behavior of all safety-relatedmessage transmissions even at peak-load. In addition tohard real-time performance time-triggered control alsosupports temporal composability and facilitates the re-alization of fault-tolerance mechanisms. For this reasonthe communication infrastructure for the steer-by-wire,the brake-by-wire, the powertrain, the vehicle dynam-ics, the passive safety and the external lighting DASare time-triggered virtual networks [19].

Event-triggered virtual networks, on the other hand,are the communication infrastructure of choice forthose DASs having less stringent dependability re-quirements. Here, the flexibility and the efficient use

of resources is more important than the determinismprovided by the time-triggered control paradigm. Forthis reason, the jobs of the interior, power manage-ment, driver control, and infotainment DAS are in-terconnected by respective event-triggered virtual net-works [19] in the presented architecture.

4.3. Gateways

By splitting the overall functionality of the car intomultiple DASs the need for a coupling of individualDASs emerges. The presented architecture supportsgateways as a generic architectural services for the in-terconnection of DASs. Gateways have significant ad-vantages with respect to the elimination of resourceduplication and the tactic coordination of applicationsubsystems. In a large automotive system, different ap-plication subsystems typically depend on the same orsimilar sensory inputs and computations. Gateways al-low to exploit system-wide redundancy of sensor in-formation in order to increase reliability or reduce re-source duplication. In addition, gateways permit thecoordination of DASs in order to improve quality ofcontrol.

In the DECOS integrated architecture, we sharplydistinguish between architecture level and applicationlevel. Based on this differentiation, we can identify twochoices for the construction of a gateway. A hiddengateway performs the interconnection of virtual net-works at the architecture level. Generic architecturalservices – although parameterized by the applicationrequirements – are transparent to the jobs at the ap-plication level. A visible gateway, on the other hand,performs the interconnection at the application level.

A virtual gateway [18] interconnects two virtual net-works of two respective DASs by forwarding informa-tion contained in the messages received at the inputports of one virtual network onto the output ports to-wards the other virtual network.

In general, the semantic and operational propertiesof the input ports at one virtual network can be dif-ferent to the semantic and operational properties ofthe output ports at the other virtual network. The re-sulting property mismatch [4] is resolved by the gate-way by performing transformations on the informationpassing through the gateway. For syntactic transforma-tions, the gateway requires a description of the syntac-tic format (i.e. the data types) of the messages pass-ing through the gateway and rules for transforming thedifferent syntactic transformations into each other. Ifthe DASs interconnected by the gateway exhibit dif-ferent operational specification styles [14], the gatewayrequires additional buffering functionality for the ex-change of information between virtual networks with

Airbag Driver

Airbag Pass.

VirtualGateway

VirtualGateway

Yawrate/Lateral Acc.

SensorFT PedalSensor 3

Clima DriverDoor

LIN LEFT DOOR CLUSTER

Virtual Event-Trigged Network of the Interior DAS

Window Lifter

Module

Mirror Module

Anti-Puddle Lighting

Door Lock

Module

Switch Panel

LIN RIGHT DOOR CLUSTER

Window Lifter

Module

Mirror Module

Anti-Puddle Lighting

Door Lock

Module

Switch Panel

Physical LIN

Gateway

Physical LIN

Gateway

Vehicle Dynamics DAS Passive Safety DAS

VirtualGateway

Engine Control

AutomaticGear

Powertrain DAS Interior DAS

Figure 5. Physical and Virtual Gateways of the Interior DAS

varying rigidity of temporal specifications. For exam-ple, such a scenario occurs, if one DAS operates time-triggered and the second DAS operates event-triggered.

In addition, virtual gateways ensure encapsulationby using a filtering specification in the value and tem-poral domain in order to restrict the redirection of mes-sages through the gateway. In general, only a fractionof the information exchanged at one virtual networkwill be required by jobs connected to the virtual net-work at the other side of the gateway. By restrictingthe redirection through the gateway to the informa-tion actually required by the jobs of the other DAS, thegateway not only improves resource efficiency by sav-ing bandwidth of unnecessary messages, but also facil-itates complexity control.

In addition to the interconnection of virtual net-works, the presented integrated architecture offers ar-chitectural gateway services for interacting with the en-vironment via physical gateways. In general, the inter-action of the computer system with the controlled ob-ject and the human operator can occur either via a di-rect connection to sensors and actuators or via a field-bus network. The latter approach simplifies the instal-lation – both from a logical and a physical point of view– at the expense of increased latency of sensory infor-mation and actuator control values.

Since the prevalent low-cost fieldbus protocol in theautomotive domain is LIN [17], the proposed architec-ture supports physical LIN gateways, each acting asa master for the slaves of the physical LIN bus. Fig-ure 5, which exemplifies the role of hidden gateways inthe functional structure of the future automotive archi-tecture, depicts two of these LIN gateways for the inter-connection of the interior DAS with the LIN fieldbusseslocated at the front doors. The driver door job and pas-senger door job exchange information with the actua-tors and sensors in the doors in order to control doorlocks, window lifters, mirrors, and anti-puddle light-ing.

In addition, Figure 5 also contains virtual gatewaysfor the interconnection of virtual networks. The interior

DAS constructs real-time images capturing the state ofthe passenger compartment of the vehicle (e.g., statusof the doors, seats, lighting, climate control) that arealso important to other DASs. For example, the driver’sweight as measured at a seat is an important parame-ter for the passive safety DAS in order adapt air bags todifferent passengers (e.g., children). The current tem-perature inside and outside the car, which is capturedby the climate control subsystem, is another examplefor a real-time entity that is significant beyond the in-terior DAS. Temperature measurements are an essen-tial input for physical models of sensors in other DASs(e.g., powertrain DAS) and permit to improve the pre-cision and plausibility of sensory information.

Adversely, other DASs need to be able to controlbody electronics in the interior DAS. In hazardous sit-uations, e.g., after the detection of a potential crash asindicated by yaw rate and lateral acceleration sensors(e.g., during skidding and emergency braking), the ve-hicle dynamics DAS causes the tensioning of seat-belts,realigning of seats to a safer positions.

4.4. Physical System Structure

The mapping from the functional to the physical sys-tem structure needs to assign jobs to ECUs and virtualnetworks to the time-triggered physical core network.As exemplified in Figure 6, each ECU can host mul-tiple jobs of different DASs. For instance consider theECU located in the left front of the car. On this ECUone of the three jobs comprising the steering TripleModular Redundancy (TMR) system and the job pro-viding the braking service of the left front tire are lo-cated. Furthermore, the job controlling adaptive for-ward lighting and the camera system of the left sideare scheduled on this component. In order to toleratearbitrary single component failures it is mandatory todevise a mapping of jobs to ECUs in a way, that re-dundant jobs are not hosted on the same ECU.

Similarly, the physical core network is the basis formultiple virtual networks. In order to achieve the de-

ECU

ECU ECU

ECU

ECU

ECUECUECU

StarCoupler

StarCoupler

Time-TriggeredCore Network

LIN Fieldbus

External Rear Lights

External Rear Lights

TrunkControl

Battery A

Battery B

Driver Door

Passenger Door

BackDoor

BackDoor

Door Passenger

Passenger Seat

Brake Assistant

BrakeLeft Front

Battery Management

Instrument Cluster

FT Steering Actuator 1

Adaptive Cruise

Controller 1

FT Pedal Sensor 1

FT Pedal Sensor 2

Light Positioning

LeftCamera 1

Engine Control

Automatic Gear


2Radar 1

Figure 6. Physical System Structure

pendability requirements of safety-critical DASs, thephysical core network relies on two central guardians [2]for achieving fault isolation even in case of arbitraryECU failure modes. Fault injection experiments haveshown that for ultra-dependable applications restric-tions concerning the failure modes of ECUs are unjus-tified [1].

Another prerequisite for safety-critical applicationsis the accumulation and generation based on dual bat-tery solutions. A redundant power supply scheme pro-vides the foundation for fault-tolerant energy supplyof safety-critical by-wire functionality also in case of afailure of one power supply network.

In addition, Figure 6 shows the role of gateways inthe physical structure of a car. Physical LIN gatewaysconnect physical LIN clusters to the integrated system,e.g., the LIN fieldbus within the doors of the cars areconnected to the ECUs located in the center of the car.

5. Discussion

This section summarizes the main benefits of the in-troduced integrated automotive architecture and high-lights the major design decisions. We will show that theproposed architecture is inline with prevalent architec-tural trends, such as reuse of functionality across dif-ferent car segments and introduction of safety-criticalapplications.

5.1. Economic Benefits

Present day automotive systems follow a federatedphilosophy with different types of automotive net-works [15]. The multitude of communication protocolsis a result of the different requirements with respect

to functionality, dependability, and performance of theautomotive DASs, such as the infotainment DAS, thecomfort DAS, or the powertrain DAS.

In contrast to these federated architectures, the inte-grated architecture for future automotive systems pre-sented in this paper allows to share network and com-ponent resources among different DASs in order toevolve beyond a “1 Function – 1 ECU” strategy andachieve a significant reduction in the overall number ofECUs. With an average cost of 40 Euro per ECU in to-day’s cars and 0.2 Euro per wire, the total hardwarecost of a federated automotive system with 40 ECUsand 800 wires is about 1800 Euro. If we assume that thenumber of ECUs will be reduced to 30 nodes and thenumber of wires to 500 in the integrated system, withan increased average cost per ECU of 50 Euro, then to-tal hardware cost is reduced by 200 Euro per car.

5.2. Complexity

A minimal complexity, i.e. a minimal mental effortto analyze and understand a system, is one of the mostimportant design drivers of the presented integrated ar-chitecture. Today, the unmanaged complexity of sys-tems is the major cause of design faults. Complex-ity increases the likelihood of serious, yet latent, designflaws [9, p. 39]. In [16, p. 131] it is stated that complex-ity of software and hardware causes a non linear increasein human-error induced design faults. High system com-plexity also prolongs development, which is detrimen-tal to a company’s economic success, because today’sbusiness realities demand a short time-to-market. Inaddition, complexity complicates validation and certi-fication as state-of-the-art formal verification tools arelimited in the size of a design that they can handle.

In order to manage complexity, the presented in-tegrated architecture enables designers to proceed insuch a way as if they were realizing DASs in a feder-ated system. A DAS along with the corresponding com-munication resources (virtual networks) and computa-tional resources (partitions in components) is encap-sulated and interactions between DASs are limited tothe exchange of messages via precisely specified hiddengateways. Similar to a federated architecture, the in-tegrated architecture decouples each DAS from otherDASs. Each DAS possesses a dedicated encapsulatedvirtual network. A virtual network is private for a DAS,i.e. other DASs cannot perceive or effect the exchangedmessages other than those being explicitly exported viaa gateway. By exercising this strict control over theinteractions between DASs, only the behavior of theDAS’s virtual network and the behavior of gateways isof relevance when reasoning about a DAS. The mes-sage transmissions on other virtual networks can be

abstracted from. Similarly, each job executes in a cor-responding partition, which forms an encapsulated ex-ecution environment with guaranteed component andnetwork resources. The activities of jobs executing onthe same component cannot affect the component andnetwork resource that are available to other jobs in thecomponent.

By not only supporting error containment betweenDASs, but error containment between jobs within aDAS, the integrated architecture exceeds the error con-tainment capabilities of most federated systems. Fur-thermore, the integrated architecture offers generic ar-chitectural services as a base line for application devel-opment, thus decreasing the functionality that must berealized at the application level. Such a slimmer appli-cation is easier to comprehend and leaves less room forsoftware design faults. Only the interface between thearchitecture and the application is visible to the appli-cation developer, while the realization of the architec-tural services remains hidden.

5.3. Dependability

Carmakers are on the verve of deploying by-wiretechnology to improve the functionality of the vehiclethat goes beyond traditional hydraulic and mechanicsystems. This trend requires the deployed E/E archi-tectures to meet the requirement for ultra-high depend-ability [27] (a maximum failure rate of 10−9 critical fail-ures per hour is demanded). Today’s technology doesnot support the manufacturing of electronic deviceswith failure rates low enough to meet these reliabil-ity requirements. Since ECU failure rates are in the or-der of 10−5 to 10−6, ultra-dependable applications re-quire the system as a whole to be more reliable thanany one of its ECUs. This can only be achieved by uti-lizing fault-tolerant strategies that enable the contin-ued operation of the system in the presence of ECUfailures [3].

For this reason, the integrated automotive architec-ture is based on a time-triggered base architecture witha fault-tolerant and deterministic communication sys-tem. The consistent distributed state with respect toa global sparse time base is the basis for active redun-dancy, such as TMR. Replicated star couplers use thea priori knowledge about the points in time of commu-nication activities to contain timing message failures,thus offering fault isolation even with arbitrary ECUfailure modes [1]. In addition, the proposed architec-ture offers redundancy of the power nets, supported byelectrical energy management techniques for the gener-ation, the distribution, and the accumulation of power.

Furthermore, by decreasing the number of ECUsand physical networks, the integrated automotive ar-

chitecture offers increased reliability by minimizing thenumber of connectors and wires. Field data has shownthat a significant amount of electrical failures are at-tributed to connector problems.

5.4. Flexibility

A newly developed E/E architectures is expectedto be deployable on different car segments and mod-els. Consequently, the reuse of applications in a modu-lar way is of critical importance. This issue also has animpact on “Tier 1 system suppliers” that need to adapttheir subsystem design according to this trend. The us-age of validated and possibly certified application soft-ware in combination with standard physical ECUs ondifferent models and segments of vehicles will lead toadvantages in terms of increased volume, multi-suppliermanagement, and multi-platform management. In ad-dition, not only software modules but complete elec-tronic subsystems can be made available for differentvehicle platforms. This strategy also eases the designchoices for the interior of the car, due to the freedom ofdecoupling application software from a particular phys-ical node. The integrated automotive architecture pro-vides a high degree of freedom in the allocation of jobsto ECUs and supports the migration of jobs betweenECUs (constrained by dependability requirements).

6. Conclusion

Future car generations require computer architec-tures to accommodate the need for mixed criticalityapplications, i.e. supporting applications with ultra-high dependability requirements as well as applicationswhere flexibility and resource efficiency is of primaryconcern (e.g., comfort electronics). The introduced DE-COS architecture establishes such an infrastructureand also enables physical integration by combiningmultiple DASs and virtual networks within a single dis-tributed real-time computer system. Thus, the archi-tecture reduces the number of different networks andprotocols.

The proposed integrated architecture exhibits flexi-bility and supports reuse of application software acrossdifferent car segments. The key element for this flexibil-ity, as well as for complexity management and the inde-pendent development of subsystems, are small DASs.Instead of the typical domain oriented system struc-ture, we show that we can subdivide the overall func-tionality of a car into smaller DASs, each equipped withdedicated architectural services. By transforming a to-day’s automotive system onto the future E/E architec-ture, we have demonstrated the feasibility of the inte-grated architecture for a future automotive system.

Acknowledgments

This work has been supported by the European ISTproject DECOS under project No. IST-511764.

References

[1] A.Ademaj,H. Sivencrona,G.Bauer, and J.Torin. Eval-uation of fault handling of the time-triggered architec-ture with bus and star topology. In Proceedings of the2003 International Conference on Dependable Systemsand Networks, pages 123–132, June 2003.

[2] G. Bauer, H. Kopetz, and W. Steiner. The centralguardian approach to enforce fault isolation in a time-triggered system. In Proceedings of the 6th Interna-tional Symposium on Autonomous Decentralized Sys-tems (ISADS 2003), pages 37–44, Pisa, Italy, Apr. 2003.

[3] R. Butler, J.L.Caldwell, and B. Vito. Design strat-egy for a formally verified reliable computing platform.In Proceedings of the 6th Annual Conference on Com-puter Assurance (COMPASS) Systems, pages 125–133,Gaithersburg, MD, USA, June 1991. NASA LangleyRes. Center.

[4] C. Jones et al. Final version of the DSoS conceptualmodel. DSoS Project (IST-1999-11585), Dec. 2002.

[5] W. Elmenreich. Sensor Fusion in Time-Triggered Sys-tems. PhD thesis, Technische UniversitatWien, InstitutfurTechnische Informatik,Treitlstr. 3/3/182-1, 1040Vi-enna, Austria, 2002.

[6] P. Giusto, A. Ferrari, L. Lavagno, J.-Y. Brunel,E. Fourgeau, and A. Sangiovanni-Vincentelli. Automo-tive virtual integration platforms: why’s, what’s, andhow’s. In Proceedings of the IEEE International Con-ference on Computer Design: VLSI in Computers andProcessors, pages 370–378, Sept. 2002.

[7] R. Hammett. Flight-critical distributed systems: de-signconsiderations [avionics]. IEEEAerospace andElec-tronic Systems Magazine, 18(6):30–36, June 2003.

[8] H. Heitzer. Development of a fault-tolerant steer-by-wire steering system. Auto Technology, 4:56–60, Apr.2003.

[9] S. Johnson and R. Butler. Design for validation. IEEEAerospace and Electronic Systems Magazine, 7(1):38–43, Jan. 1992.

[10] H. Kopetz. Real-Time Systems, Design Principles forDistributed Embedded Applications. Kluwer AcademicPublishers, Boston, Dordrecht, London, 1997.

[11] H. Kopetz and G. Bauer. The time-triggered architec-ture. IEEE Special Issue on Modeling and Design of Em-bedded Software, Jan. 2003.

[12] H. Kopetz and R. Obermaisser. Temporal composabil-ity. Computing & Control Engineering Journal, 13:156–162, Aug. 2002.

[13] H. Kopetz, R. Obermaisser, P. Peti, and N. Suri. Froma federated to an integrated architecture for depend-able embedded real-time systems. Technical Report 22,Technische Universitat Wien, Institut fur TechnischeInformatik, Treitlstr. 1-3/182-1, 1040 Vienna, Austria,2004.

[14] H. Kopetz and N. Suri. Compositional design of RT sys-tems: A conceptual basis for specification of linking in-terfaces. In Proceedings of the 6th IEEE InternationalSymposium on Object-Oriented Real-Time DistributedComputing, pages 51–60, May 2003.

[15] G. Leen and D. Heffernan. Expanding automotive elec-tronic systems. Computer, 35(1):88–93, Jan. 2002.

[16] N. Leveson. Software safety: why, what, and how. ACMComput. Surv., 18(2):125–163, 1986.

[17] LIN Consortium. LIN Specification Package Revision2.0, Sept. 2003.

[18] R. Obermaisser, P. Peti, and H. Kopetz. Virtual gate-ways in thedecos integratedarchitecture. InProceedingsof the Workshop on Parallel and Distributed Real-TimeSystems 2005 (WPDRTS). IEEE, Apr. 2005.

[19] R. Obermaisser, P. Peti, and H. Kopetz. Virtual net-works in an integrated time-triggered architecture. InProceedings of the Tenth IEEE International Work-shop on Object-oriented Real-time Dependable Systems(WORDS2005), Feb. 2005.

[20] G. Reichart and M. Haneberg. Key drivers for a futuresystemarchitecture in vehicles. InConvergence Interna-tional Congress, Detroit, MI, USA, October 2004. SAE.

[21] Robert Bosch Gmbh, Stuttgart, Germany. CAN Speci-fication, Version 2.0, 1991.

[22] J. Rushby. Partitioning for avionics architectures: Re-quirements, mechanisms, and assurance. NASA Con-tractor Report CR-1999-209347, NASA Langley Re-search Center, June 1999. Also to be issued by the FAA.

[23] J. Rushby. A comparison of bus architectures for safety-critical embedded systems. Technical report, ComputerScience Laboratory, SRI International, Sept. 2001.

[24] A. Saad and U. Weinmann. Intelligent automotivesystem services: Requirements, architectures and im-plementation issues. In Convergence InternationalCongress, Detroit, MI, USA, October 2004. SAE.

[25] A. Sangiovanni-Vincentelli. Defining platform-baseddesign. EEDesign of EETimes, February 2002.

[26] H. Simon. The Sciences of the Artificial. MIT Press,1996.

[27] N. Suri, C. Walter, and M. Hugue. Advances In Ultra-Dependable Distributed Systems, chapter 1. IEEE Com-puter Society Press, 10662 Los Vaqueros Circle, P.O.Box 3014, Los Alamitos, CA 90720-1264, 1995.

[28] J. Swingler and J. McBride. The degradation of roadtested automotive connectors. InProceedings of the 45thIEEE Holm Conference on Electrical Contacts, pages146–152, Pittsburgh, PA, USA, Oct. 1999. Dept. ofMech. Eng., Southampton Univ.

an integrated architecture for future car generations

Documents