ELECTRONIC AUTOMOTIVE REQUIREMENT DESIGN SPACE

A Bird’s Eye View of a Strategic Requirement Design Space Exploration

Liliana Díaz-Olavarrieta, David Báez-López

Fundación UDLA. Puebla, Dept. Electronics and Communications, 100 Sta.Catarina Mártir, San Andrés, Puebla, Mexico

Keywords: Automotive Requirements Specification Design Space, Strategic Consistency

, Specification Completeness,

Distributed Systems, Real-time Systems, Communications & Control Automotive Networks, Fault

Tolerance, Time-triggered protocols, Event-triggered protocols, Safety Critical Applications, User-centered.

Abstract: The purpose of this article is to make a holistic compilation of many different types of requirements for an

automotive electronic communications / control network (though the framework is in itself more generally

applicable), and organize them into an easily reusable framework. Requirements have to be correct,

consistent and complete. The issue of correctness of the specification should be dealt with formal validation

models. The issue of consistency can be handled through domain expert specification reviews. The

completeness issue can be dealt with by comparison with a reference, and this paper proposes a metamodel

to help with the completeness and strategic consistency issues in the requirement specification process. The

requirements framework proposed in this paper aims to answer the question: “What is the requirements

design space for an automotive electronic communications network?”, and help in the completeness of the

requirements specification through a holistic, multi-perspective, Bird’s Eye View. The main perspectives

that will be examined in this requirements design space exploration are four: a) The “Nature of the User”

perspective, b) The “Nature of the Application” perspective: Distributed, Real time, Safety-Critical

applications, and Resource Constraints requirements, c) The “Nature of the Process Development”

perspective, in particular, the component based development (CBD) process of Electronic Subsystem

Design within Automotive Companies: component architecting, component assembly and component

provisioning, and d) The “Nature of the Industry” is given by the competitive environment: Suppliers,

Substitute Products, Substitute Technologies, Competitors, Potential Industy Entrants, the Company and its

Clients.

1 INTRODUCTION

The global demand for vehicle electronics – which

are distributed, heterogeneous, real time systems- is

forecast to reach nearly $75 billion by 2005, and the

percentage of automotive electronics cost in 2010

will grow from 12 % to 30 % of a mid-range car's

total cost (Mayer, 2005). The design and

implementation of heterogeneous, real-time,

distributed systems is a complex, knowledge

intensive, problem. The design of embedded

electronic distributed real-time systems for

automotive applications, even more so. The

complexity comes not only from the electronics, but

from all the non-electronic automotive parts which

interact with, and constrain, the electronic systems.

The automotive electronic cont

rol applications

range from non-critical comfort level functions such

as doors, lights, mirrors, window and seat control, to

critical-safety applications (where human life is at

risk if the electronic system fails) or image-critical

functions, such as being able to get into a locked car

through the door. In critical activities, generically X-

by-wire applications, (Kopetz,1995), taking their

name from the first “Fly-by-Wire” (FBW) Aircraft

systems, fault-tolerance has to be guaranteed. The

first all digital FBW application without mechanical

backup was the F-8 military aircraft (1972), while

the first commercial aircraft, which entered service

in 1988 with Fly-by-Wire technology, was the A320.

At Boeing, research on FBW prototypes began in

1986 led by GE & Allied Signal, and the first full

FBW civil commercial aircraft was the Boeing 777

(1995), and used the fault-tolerant SafeBus™

protocol (Rushby, 2001), and had 3 primary flight

computers, 3 completely redundant physically and

electrically separate ARINC 629 Databuses, 4

147

Díaz-Olavarrieta L. and Báez-López D. (2005).

ELECTRONIC AUTOMOTIVE REQUIREMENT DESIGN SPACE - A Bird’s Eye View of a Strategic Requirement Design Space Exploration.

In Proceedings of the Second International Conference on Informatics in Control, Automation and Robotics, pages 147-153

DOI: 10.5220/0001191001470153

 SciTePress

Actuator ECUs, Sensors, and an Airplane

Information Managemtent System (Ong, 2003).

In contrast, a high-end automobile today has

more electronic functionality than a fault-tolerant

aircraft had a decade ago: a BMW Mini Cooper, has

between 7 and 23 ECUs (Electronic Control Units)

depending on the configuration, with a higher degree

of integration (Mayer, 2005), used for both critical

and non-critical applications. As there are

opportunities for electronic design functionality

increase in the automobile, there are also

completeness specification challenges and questions:

How does one ensure the requirements’

completeness, consistency and correctness?

What are the user’s expectations and service trends

that one should consider?

How can one produce a “strategically consistent”

automotive requirement?

What is the best way to categorize non-critical, or Y-

critical applications? (Y= safety, image, cost with

the highest priority).

What automotive electronic requirements are

derived from external (to the company)/ internal

perspective analysis?

How can one make a probabilistic, context-

customizable, priority-based decision?

What communications protocol subset is appropriate

to comply with the specification, among the

automotive protocols available?

This paper attempts to give answers to the first three

questions above, while the remaining issues will be

addressed in other papers.

The requirements framework Bird’s Eye View

meta-model proposed in this paper aims to answer

the question 1) What is the requirements design

space (taken from different perspectives) for an

automotive electronic communications network?

This is the first phase in the design of an

application, and the problem of matching a subset of

protocol communications to a given probabilistic,

priority oriented, context customizable requirement

specification.

The paper is organized as follows: Section 2

presents Requirements Analysis: Perspectives and

Design Space Exploration; Section 3 will present a

brief overview of In-Vehicle Networks, Standard

and safety-critical automotive protocols; Section 4

presents the USER requirements perspective;

Section 5 presents the APPLICATION requirements.

Section 6 presents the (CBD) Company

Development Process perspective and finally,

Section 7 presents the INDUSTRY perspective. In

Section 8 we present Conclusions, Section 9 are the

Acknwoledgements and Section 10 includes the

Bibliography used.

2 REQUIREMENTS ANALYSIS:

PERSPECTIVES AND DESIGN

SPACE EXPLORATION

The analysis of requirements will be done through a

user-guided perspective kaleidoscope, with the high

level bird’s view perspective inspired from

competitive business analysis (Porter, 1988), and

the lower requirements perspective driven from

safety critical and non-critical applications. The four

main requirements perspectives to examine are:

1) USER: Requirements derived from the Client

himself/herself, or Market Specific User Resource

Constraints (i.e. Selling Cost, Speed Limits, Market

Trends, Financing, Re-configurability);

2) APPLICATION: Requirements derived from the

Nature of the Application: Distributed, Real time,

Safety-Critical, Resource Constraints (Standards,

Regulations, Supplier Offerings);

3) COMPANY Requirements derived from the

CBD-based (CBDP, 2005) Automotive Component

based DESIGN & DEVELOPMENT PROCESSES.

4) INDUSTRY: Requirements derived from the

automotive industry competitive environment

according to Michael Porter’s Competitive Strategy

model (Porter, 1988).

The exploration of the requirements design space

is the first step to design user oriented electronic

automotive control applications. The design of a

specification requirement for an application is the

second step, and once the requirement specification

has been decided upon, a designer must match the

application requirements to a small subset of

communications protocols, to implement the IVN.

3 IN-VEHICLE NETWORKS (IVN)

There are more than 42 protocols (proprietary or

standard) and structural topologies (nominally called

“busses”) for in-vehicle communication and control

networks and industrial applications in different

categories. There are Emissions/Diagnostics, Mobile

Media and “X-By-Wire” protocols, which are used

for different applications within the automobile

sector (Automotive Buses, 2005). Also by speed

there are SAE’s Class A (low speed applications, bit

rate < 10 Kb/s), Class B (medium speed, between

10kb/s and 125 kb/s for general information

transfer), Class C (high speed, bit rates higher than

125 Kb/s), and Class D protocols (for speeds > 1

Mb/s) -though there are no SAE implemented Class

D protocols (Bell, 2002). Only those automotive

protocols with standard potential are considered

below.

ICINCO 2005 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

148

3.1 Standard Automotive Protocols

There seems to be a growing consensus within the

industry that the communications protocols that will

prevail are amongst the following selected few:

LIN (Alford, 2003), (LIN, 2005), CAN and

derivatives: L-CAN, CAN, TT-CAN (TTTech,

2004), FTT-CAN (Flexible TT-CAN), TTP/A or

TTP/C (Kopetz, 1995), FlexRay (FlexRay, 2004)

and MOST (Kibler, 2004).

3.2 Safety-Critical Protocols

An important distinction to match a protocol to the

application is if the protocol is apt to implement a

safety-critical fault tolerant application. There is a

general opinion that time-triggered protocols are

better suited than event-triggered protocols for

safety-critical applications (Kopetz, 2003). CAN,

LIN, and FlexRay are event triggered protocols, and

TTP, TT-CAN, FTT-CAN, MOST and FlexRay are

time-triggered protocols such as. TT-CAN and

FlexRay carry identifiers, like event triggered

protocols, while FlexRay and FTT-CAN can both

handle time-triggered and event triggered

transmission. However, the only protocols which are

accepted as fault-tolerant for safety-critical

applications are: TTA/TTP and SAFEBus™, (used

in the avionics and automotive industries), SPIDER

(non-commercial), and FlexRay (Rushby, 2001).

The first view in the requirements design space is

the user perspective, considered below.

4 USER REQUIREMENTS

Imagine we arrive walking to a high-end car. An RF

wireless signal will be used to inactivate the alarm

system, and this event will trigger the opening of the

locks wirelessly and remotely, with an RF signal,

before a chivalrous virtual agent opens the car door

automatically for you. Placing the key on the

ignition, the person detector identifies the driver and

adjusts the seat height, distance to pedals, and wheel

tilt. Then, the window manager decides if it should

open the roof window (only if it is not raining), and

the light manager decides if the interior lights should

be turned on or not at all, while activating the “back

massage with seat-belt” feature. The CD/DVD

player will set itself to the latest interrupted song

position, or ask you verbally what type of song you

want played from the iShuffle™ /iPod™ FireWire

cable you just connected into the IDB 1394 network.

A speech recognition system will transform your

answer into a command to the Dolby surround music

system, while the IVN is receiving my finger´s

destination point on a GPS/Galileo Navigation Map,

and trying to compute the best route to get to my

destination. Meanwhile, I may plug my Bluetooth

enabled PDA/Cell phone to download to a

“navigating secretary” my day’s client visit agenda,

while it finds the best scheduling and routes to

match the agenda, calculates approximate arrival

time, and automatically calls my clients and

schedules an arrival time. Then, I download the

shopping list from my PDA and send it, with a push-

of-a-button, to the nearest Bluetooth discovered

supermarket, so that the groceries are sent to my

house before I arrive home to cook at lunchtime.

This is but one imaginary use case of the myriads

of one-of-a-kind scenarios we can think of, which

require interaction of the IVN with external

communication networks and which we cannot use

directly as a specification, unless it represents a

“generic user”, defined by the strategic direction of

the company, as the “market target”. In order to

approach a “generic, reconfigurable” use case, and

translate it to a UML model, we may categorize the

use scenario as:

Goal-Driven Use Cases: Defined by hierarchical

successive refinement of the goals and sub-goals.

Context-driven Use cases: Sub-goals are reviewed in

the light of differing environment or context

scenarios such as Weather, Traffic Situation, Control

Lever, Brake Position, Accelerator position, to

refine use cases for the distinct context scenarios.

Reconfigurable (Both in Goal and in Context)

Parameterized or flexible use cases, to form the

“generic” strategically consistent use case to define

the “target market segment” user requirements.

These “more generic” IVN requirements can be

inspired in service extension models such as the

“UMTS 5Ms” model, explained below.

4.1 A User Trend Example: 5M’s

User expectation trends in terms of service for

multimedia wireless communications –voice, data,

video- have been named by the 3G UMTS Forum

as the “UMTS” “5Ms for Service Extension”:

Movement, Moment, Me, Money and Machine:

Movement: To escape a Fixed place, a memory,

virtually and literally in a car, while keeping

connected. A recurrent user requirement is to be

always connected to the large variety of LANs,

WANs, MANs, and global external networks to

enable personal mobile communications, such as

Bluetooth,WiFi (802.11), GSM/GPRS/EDGE or any

of the 5 versions of the IMT-2000 standard for

cellular voice, data and multimedia.

ELECTRONIC AUTOMOTIVE REQUIREMENT DESIGN SPACE - A Bird’s Eye View of a Strategic Requirement

Design Space Exploration

149

Moment: Comfort Function Control to improve

the experience of present and Moment. Also, to

expand the concept of time, from Discrete to

Continuous / Past, present, future / Scenarios /

Experiences into the Memory. Memory is enabled

with emotion, and emotion with sense involvement.

Appeal to the 5 senses (eyes, ears, taste, smell,

touch) to create a better “moment” or “infotainment”

experience. Eyes: Digital TV, in the shape of DVB-

H, an open industry standard for the delivery of

mobile broadcast digital TV, via satellite; Ears:

DAB: Digital Audio Broadcast / Music download

capability; Eyes/Ears/Touch: Entertainment

Multimedia applications for collaborative and

interactive games, video streaming. Taste/smell is

still open to new “better moment” creation, and New

Magic Worlds applications. (“Mobile Virtual” on the

road Eating/Drinking/Smelling experiences?)

Me: The person and its expansion to a

Community. Shared Access / Interactivity /

Authentication / Shared Interests. Interactive

Gaming or Collaboration. The car as a member of a

community of services. Branding and Self-

configurability, as expression of oneself, not only of

“settings”, but car “look” and functionality, based on

electronic added-value The car as a personal

extension of home or office, with Business

Broadband Internet capability for Videoconferences

and mobile Multi-site virtual meetings.

Money: Financial Services. Requires Wireless

Security / Heterogeneous Networks / Broadband

Anytime. Allows E-mobile commerce. Banking

mobile applications, which also have to be made

fault-tolerant and safe, a challenge with wireless

connections implicit in the mobile car status. Money

means also Cost to the User, in life-cycle terms

(acquisition cost, operation, maintainability,

insurance - prices should be lower for certified fault

tolerant cars-, disposal/ recycling cost). Cost for the

company is considered in the Industry perspective.

Machine: Empowering Gadgets & Devices.

Added Processing Intelligence, with Power

availability, and a “universal dock connection

capability” to connect PDAs, Tablets, iPods, and

charge Cell phones, will justify the trend towards a

14V/42V power network in future cars (Leen, 2002).

Another machine trend is the automobile as an

intelligent set of services, on a mechanical support

“envelope”. This would enable the design of Active

Safety / Intelligent automobile systems such as

Telematics, and adaptive electronic steering, braking

or other power-train control applications - with

augmented proactive safety and predicting capability

to take over the driver in case of danger (falling

asleep and approaching an obstacle too closely).

5 NATURE OF THE

APPLICATION

In the context of Automotive Communications and

Control Electronic Subsystems, the four

characteristics that emerge as defining the “nature of

the application” are: 1) the distributed nature of the

network, 2) The real time application requirements

for some of the subsystems, 3) The safety-critical

requirements for X-by-wire applications, for

example, and 4) The Resource Constraints, which is

derived from the implementation of the application.

We examine, briefly, the “application nature” below.

5.1 Distributed Networks

A distributed network (Kopetz, 1997), (Tanenbaum,

2002), (Coulouris, 2001) is usually recognized

because there are concurrent processes running in

parallel on various processors, there is a distributed

memory or shared state, and data is communicated

through an interconnection medium (copper, fibre or

wireless link) that links the multiple processors and

the storage recipients, be they volatile or non-

volatile, or stable storage (a mixture of both).

Concurrency of processes over a distributed

network implies that communication and access to

the controllers has to be arbitrated. Concurrent can

be either programmed and without contention, such

as in TDMA, FTDMA, FDMA, CDMA access

schemes, or random assigned schemes with resource

contention and possible collisions, such as in

CSMA/CD/CA/CR or DAMA (Demand Assigned

Multiple Access).

Independently of its classification, a distributed

network implementation should be “invisible” to the

user, i.e., the system should be transparent in the

way processes communicate, the way they are

scheduled and synchronized, independently of what

functionality the interconnected ECUs have. We

expand on these three requirements below.

5.1.1 Transparency

The transparency requirement means that the user

should not be able to distinguish between the

performance of a uniprocessor central controller

architecture, and a multiprocessor distributed

architecture, except perhaps for increased efficiency.

Various types of transparency that can occur are the

following:

Access: Local and Remote Resources are accessed

using identical operations

Location: Users cannot tell where HW and SW

resources are located

ICINCO 2005 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

150

Migration - Mobility: Resources should be able to

move without having their “names” changed.

Replication: System replicates critical data, without

the user noticing it, for increased performance and

reliability.

Concurrency: Users- processes will not notice the

entry of other users in the system, even if they share

the same resources.

Failure: Failure transparency implies fault

independence, fail-silence, fail-operational, and fail-

safe modes, so that if one part fails, the whole

system does not come to a halt.

Performance: Load variation should not lead to

performance degradation.

5.1.2 Inter-Process Communication

The separation of concerns between the

Functionality of Processes vs. their Communication

(which also require Scheduling and Synchronization

among them) is an important requirement for later

reusability of the designs.

All four types of behavior: function execution in

controllers, synchronization, scheduling and finally

the communication itself, take time. That is, one

should consider realistic delay assumptions for

communication (sending messages across an

interconnect network) due to signal propagation

delays, processor “interpretation”, execution of

processes, synchronization and scheduling delays.

This means that during model simulation of an

intended application, realistic delay assumptions

have to be included in an imported zero delay

ASCET-SD (ETAS, 1998), model and re-simulated,

as is done, for example, in the VCC –Virtual

Component Co-design- tool (Demmeler, 2001).

5.1.3 Inter-Process Synchronization

There are two types of process synchronization: a)

synchronous or periodic, also called Time-triggered

and b) asynchronous or aperiodic also called Event-

triggered, (where specific Event signals act as the

triggers to change state).

Inter-process synchronization is obtained by a

global clock for time-triggered protocols, and by an

arbiter, a “bus guardian” or “central guardian”

(using the FlexRay or TTP terminology) which

controls the handshaking communication for an

event-triggered protocol. In both cases, there is a

structural entity, the clock generator, in the

synchronous case, or the arbiter, in the asynchronous

case, which implement the synchronization. For

process synchronization, it is important to schedule

the order and timing of access to the network,

through Inter-process Scheduling.

5.2 Inter-Process Scheduling

Scheduling amongst processes refers to the way

tasks or processes are prioritized to give a fair share

of access to all the processes from ECU nodes to the

shared distributed, interconnection network.

Depending on the topology, there exist centralized

(i.e. Daisy-chain) and distributed scheduling

algorithms (i.e. Token passing methods).

Concurrency of processes over a distributed

network implies that communication and access to

the controllers has to be arbitrated. Concurrent

access is made through the shared medium –copper,

fibre, wireless- and can be either programmed and

without contention, such as in TDMA (TTP),

FTDMA (FlexRay), FDMA (Bluetooth), CDMA

(WCDMA -3G cellular), or minislotting access

methods (used by ARINC 629, and Byteflight), or

random assigned schemes with resource contention

and possible collisions (CSMA/CD/CA/CR or

DAMA (Demand Assigned Multiple Access) -CAN.

These access schemes motivate a triggering

classification for protocols, related to the

synchronicity or periodicity of events: time-triggered

or synchronous, or periodic protocols, vs. event-

triggered, or asynchronous, or aperiodic protocols.

This classification is not the only one, as we can

also classify protocols by their push/pull

characteristics, periodicity, and message broadcast

mode (Kopetz, 1997) or by their message broadcast

mode (one to one, one to many, many to one, and

many to many) (Kopetz, 1997). Client initiated

transactions are called push oriented while server

initiated transactions are called pull oriented.

Whatever the category, they may be in Real-Time.

5.3 Real-Time Requirements

Real – time requirements are sometimes also part of

the distributed applications nature of the information

required. When this is the case, it is often related to

Safety Critical applications (Kopetz, 1995), (Dilger,

1997), (Merceron, 2001). Here, we only list the

requirements implicit in the Real time Nature of an

Application (Kopetz, 1995), due to space

constraints, stressing its importance: Timeliness of

Response, Protectiveness, Real-time Scheduling,

Real-time Communication, Clock Synchronization,

Membership Services, Composability, Error-

Detection, Robustness, Fault Independence

/Tolerance, Faults and Failure Modes for Safety-

critical applications in the Automotive Industry.

ELECTRONIC AUTOMOTIVE REQUIREMENT DESIGN SPACE - A Bird’s Eye View of a Strategic Requirement

Design Space Exploration

151

6 CBD: DEVELOPMENT

PROCESS

A CBD (Component Based Design Process), typical

of the automotive industry, consists of (CBDP,

2005): component architecting (specifying to

second-tier development firms in the semiconductor

business and constructing their own design),

component assembly (parts provided by first-tier

suppliers such as Bosch, Siemens and Magneti-

Marelli) and component provisioning (often by third

parties) to form subsystems with ICs from Motorola,

Texas Instruments, Hitachi & ST Microelectronics.

7 NATURE OF THE INDUSTRY

The automotive industry has a competitive context

made of (Porter, 1988): Suppliers, Substitute

Products-Technologies, Competitors and Potential

Entrants, Clients (considered in User Requirements),

and the Company itself, which have to be analyzed

to search for industry context imposed

requirements.

Furthermore, the “Nature of the Industry” can be

static or dynamic (trends and direction). The static

perspective from a strategic point of view considered

was developed by Michael Porter (Porter, 1988) to

analyze the competitive environment of a company

in a given industry. The dynamic model considers

each of these views and their evolution in time, and

should also be considered to produce strategically

relevant, scalable and updateable automotive IVNs.

8 CONCLUSIONS

This paper has introduced a novel, holistic

“automotive requirements meta-model” to analyze

requirements for the design of a distributed,

(sometimes real-time), (always) heterogeneous

system, for (safety-critical) user functions and create

complete, strategically consistent requirements,

viewed from four different perspectives: User,

Application, Development Process and Industry.

ACKNOWLEDGEMENTS

The authors would like to acknowledge support from

CENTIA/DIP, & UDLA Electrical Engineering

Dept.

REFERENCES

Alford, C., Paskvan, J., 2003. “Local Interconnect

Network: Hands-on LIN Training”, retrieved March

2005, from Volcano Automotive Group Website.

Automotive Buses, 2005. “Logic Design Information:

Automotive Buses”, retrieved Feb 4, 2005 from

http://www.interfacebus.com/Design_Connector_Auto

motive. Bell, J., 2002. “Network Protocols used in the

automotive industry”, Doc. Ref SD/TR/PRO/01, July

24. 2002.

Byteflight, 2005. Available at

http://www.byteflight.com/

CBDP, 2005. “Chapter 30 - Component-Based

Development”, SEPA 6/e, Downloadable Reference

Library, available from

http://www.rspa.com/reflib/CBSE.html, April 2005.

Coulouris, G., Dollimore, J., Kindberg, T., 2001.

“Distributed Systems – Concepts and Design”,

Addison Wesley Publ. Comp., 3ed., 2001.

Demmeler, T., Giusto, P., 2001. “A Universal

Communication Model for an Automotive System

Integration Platform”, IEEE Proc. 1530-1591/01, pp.

47-54, 2001.

Dilger, E., et al., 1997. “Towards an Architecture for

Safety Related Fault Tolerant Systems in Vehicles”,

On-line document available at

http://www.vmars.tuwien.ac.at/projects/xbywire/proje

cts/new-esrel97.html

ETAS GmbH, 1998. “Whitepaper ASCET-SD, ETAS

GmbH, 1998”, mentioned (Demmeler, 2001) above.

FlexRay, 2004., “FlexRay Communications System,

Protocol Specification, Version 2.0”, June 2004,

retrieved on February 1, 2005 from FlexRay site at

http://www.flexray.com/specification_request.php.

Kibler, T., Zeeb, E., 2004. “Optical Data Links for

Automotive Applications”, IEEE Proceedings

Electronic Components and Technology Conference,

pp., 1360-1370, 2004.

Kopetz, H., 1995. “A Comparison of CAN and TTP”,

available from TTTech website:

http://www.tttech.com/technology/articles.htm

Kopetz, H., 1997, “Design Principles for Distributed

Embedded Applications”, Kluwer Academic

Publishers, 1997.

Kopetz, H., 1998, “TTP – A New Approach to Solving the

Interoperability Problem of Independently Developed

ECUs”, On-line Document Available from

http://www.vmar.tuwien.ac.at/projects/xbywire/project

s/new-ecu.html

, on February 1

, 2005.

Kopetz, H., 2003. “Fault Containment and Error

Detection in the Time-Triggered Architecture”, Proc.

of the Sixth International Symp. On Autonomous

Decentralized Systems (ISADS´03).

LIN, 2005. Local Interconnect Network protocol website

available at

http://www.lin-subbus.org/.

Mayer, A., 2005, “Innovation is accelerating in the

Automotive Electronics”, Compiler, retrieved from

http://www.synopsys.com/news/pubs/compiler/art1lea

d_bmw-1101.html

ICINCO 2005 - INTELLIGENT CONTROL SYSTEMS AND OPTIMIZATION

152

Merceron, A., 2001. “Proving “no Cliques” in a Protocol

(TTP/C)”, IEEE Proc. 1530-0900/01, pp. 134-139.

Ong, E., 2003, “From Anonymity to Ubiquity: A Study of

Our Increasing Reliance on Fault-Tolerant

Computing”, MIT SERL, NASA Goddard OLD

Presentation, Dec. 9, 2003.

Porter, M., 1988. “Competitive Strategy”, Free Press Ed.,

1988.

Rushby, J., 2001. “Bus Architectures for Safety-Critical

Embedded Systems”, Proceedings of EMSOFT 2001,

8-10, Oct. 2001, Lake Tahoe, CA. Springer-Verlag

LNCS

Tanenbaum, A.S., Van Steen, M., 2002. “Distributed

Systems”, Prentice Hall International, 2002.

TTTech 2004, “CAN/TTCAN – Byteflight-FlexRay-TTP:

Technical Comparison of protocol properties with a

focus on safety-related applications”, PPT presentation

available at TTTech Website on

http://www.tttech.com.

ELECTRONIC AUTOMOTIVE REQUIREMENT DESIGN SPACE - A Bird’s Eye View of a Strategic Requirement

Design Space Exploration

153