See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/3363624
`
`Digital networks in the automotive vehicle
`
`Article in Computing and Control Engineering · January 2000
`
`DOI: 10.1049/ccej:19990604 · Source: IEEE Xplore
`
`READS
`2,349
`
`CITATIONS
`82
`
`3 authors, including:
`
`Gabriel Leen
`University of Limerick
`
`86 PUBLICATIONS 841 CITATIONS
`
`SEE PROFILE
`
`Available from: Gabriel Leen
`Retrieved on: 09 October 2016
`
`Page 1 of 18
`
`Mercedes Exhibit 1016
`
`

`
`Digital Networks in the Automotive Vehicle
`
`By Gabriel Leen1, Donal Heffernan1, and Alan Dunne2
`
`Nothing stands still for long in the world of electronics. The automotive industry is party to this phenomenon and is
`
`fast becoming a breeding ground for binary electronic life forms. Today’s vehicles include a complex symbiosis of
`
`intelligent electronic systems and integrated mechanical structures. The rapid growth of the computer industry has
`
`spawned a host of modern solutions and opportunities for automotive systems. It could be argued that the electronics
`
`revolution of the past two decades is the single biggest driving force behind the evolution of the motor car. Today,
`
`electronic components and systems account for over 20% of the cost of a high-end passenger car, and this percentage
`
`figure is increasing rapidly.
`
`The customer is demanding more and more sophisticated features at an affordable price. The automotive
`
`manufacturers are competing to meet such customer demands within the market price envelope. New regulatory safety
`
`and fuel related standards (emissions, fuel efficiency etc.) are presenting further challenges to the manufacturers.
`
`Electronic systems now provide the technology to enable the manufacturer to deliver new features and to meet the
`
`mandatory regulation requirements in a cost-effective manner. Vehicle electronic systems are now common place and
`
`are growing in terms of both quantity and complexity. In this paper we take a glimpse under the hood of the modern
`
`vehicle to provide an insight into the world of automotive electronics, with special emphasis on the networking aspects
`
`of these electronic systems.
`
`Developments in automotive networks
`
`Up until recently the in-vehicle communication between simple devices such as switches and actuators was achieved
`
`using point-to-point wiring; resulting in bulky, expensive, and complicated wiring harnesses which were difficult to
`
`manufacture and install. With the expanding number of features within the vehicle the amount of wiring grew to a stage
`
`where the volume, reliability and weight became a real problem. Figure 1 shows the growth of vehicle wiring
`
`requirements for Volvo passenger cars over nearly eight decadesi. The problems associated with the vast amount of
`
`vehicle wiring can be summarised as follows:
`
`(cid:216) shrinking layout space
`
`(cid:216) manufacturing and assembly difficulties
`
`(cid:216) deterioration of serviceability
`
`(cid:216)
`
`the cost/benefit ratio, does not encourage when adding additional functions at the expense of extra wiring
`
`Page 1 of17
`
`IEE_Draft_1.Doc
`
`Page 2 of 18
`
`

`
`(cid:216)
`
`increased emphasis on fuel efficiency and performance (acceleration, deceleration) requires reduction in vehicle
`
`weight
`
`(cid:216) sensor/input data being inefficiently distributed by multiple discrete signal channels
`
`(cid:216)
`
`the numerous connectors lead to unreliable operation; each link reducing the mean time between failure
`
`Growth of wiring
`
`1400
`1200
`1000
`800
`600
`400
`200
`0
`
`Total length in meters
`
`2000
`
`1995
`
`1990
`
`1985
`
`1980
`
`1975
`
`1970
`
`1965
`
`1960
`
`1955
`
`1950
`
`1945
`
`1940
`
`1935
`
`1930
`
`1925
`
`1920
`
`1915
`
`Figure 1 Growth of Automotive Wiring
`
`The need to reduce the vehicle wiring content and to improve the distribution of control and monitoring functions
`
`within the vehicle became apparent over the years and solutions for vehicle networking started to emerge during the
`
`1980s. Figure 2 charts this historical progression and shows many of the early and current vehicle networking
`
`solutionsii. Many of the technical concepts for vehicle networking were borrowed from developments in the area of
`
`computer data networks but vehicle communication requirements are driven by control strategies rather than by
`
`classical data transfer strategies.
`
`Page 2 of17
`
`IEE_Draft_1.Doc
`
`Page 3 of 18
`
`

`
`~'80
`
`'81
`
`'82
`
`'83 '84 '85 '86 '87 '88 '89 '90 '91 '92 '93
`GM CADILLAC(Body control module)
`Toyota SOARER(Electric Multi Vision)
`
`'94
`
`'95 '96 '97 '98
`
`'99~
`
`Nissan Cedric (Remote Control)
`Nissan LEOPARD(Steering Switch)
`Mitsubishi DEVONAIR(Remote Control)
`Toyota CROWN(CD-ROM)
`
`Toyota MARK II (Door multiplexing)
`
`Salplex(Series 4000 CLASS A)
`
`Mazda&Mitsubishi Electric(SWS)
`Salplex
`UTA(4-core shielded system)
`GM BUICK RIVERA(CTR Display)
`GM ALLANTE(GMUX)
`Nissan CEDRIC(Door Switch system)
`Nissan(Diagnostic Data Link Protocol)
`Toyota CROWN(Electro Multi Vision)
`Alfa Romeo(DAN)
`Daihatsu
`General Instrument(AUTOLAN)
`
`Nissan INFINITY (IVMS)
`
`GM(Door seat system)
`Motorola(Moto-car)
`Toyota CENTURY(Door optical system)
`Hitachi(Single fiber bi-directional communication)
`
`Codenoll Technology Corp.(Star coupler system)
`
`Delphi, Network Vehicle (MML)
`
`Mazda&Furukawa(PALMNET)
`Mazda COSMO (PALMNET)
`
`Mazda&Furukawa (Advanced PALMNET)
`
`Furukawa (High Reliability Physical Layer)
`
`National Semiconductor(Body load multipleximg)
`Philips&Signetics(D2B Twister Pair)
`Bosch(CAN)
`Ford(VNP)
`Chrysler(CCD)
`
`Chrysler NEW YORKER (CCD)
`Chrysler LHcar(CCD)
`Volkswagen(ABUB)
`Pioneer (IPBus)
`Renault&PSA Peugeot-Citron(VAN)
`
`Experimental system
`Production system
`
`SAE (J1850)
`
`GM(DLCS)
`Yazaki
`
`Ford (ACP)
`
`Toyota CROWN (i-Four)
`Toyota(Token bus)
`Mitsubishi(MICS)
`
`SAE (J1939)
`
`University of Vienna
`(TTP)
`
`Toyota (BEAN)
`
`Philips (PLANET)
`
`Mercedes 600SEL(CAN)
`
`Lucas(Star coupler system)
`C&C Electronics, Becker (D2B Optical)
`Furukawa(TOM: Total Optical Multiplexing)
`GM(Token bus)
`
`Most Co-operative (MOST)
`
`BMW, Motorola
` (SI)
`
`Year
`Type
`
`Electrical
`
`Optical
`
`Electrical
`
`Optical
`
`Electrical
`
`Optical
`
`Point to Point
`
`Centralised Network
`
`Distributed Network
`
`Figure 2 Automotive Network Development
`
`In the early days of vehicle networking development there was little interest in devising common networking standards.
`
`Many of the early networks made use of custom circuits and generic UART (Universal Asynchronous
`
`Receiver/Transmitter) devices to provide simple serial communication links. This approach was acceptable at the time,
`
`as then most manufacturers were vertically integrated and not as highly dependent on external suppliers, as they are
`
`today. As confidence grew and the benefits of adopting a standardised networking approach became more apparent,
`
`external suppliers were commissioned to develop increasingly more sophisticated modules which finally resulted in a
`
`move away from proprietary interfaces in favour of industry-wide standardised protocols. The standardisation of
`
`protocols helped facilitate the integration of systems developed by different suppliers, leading to a type of ‘open
`
`architecture’, and added a degree of composability to the system design process. In-vehicle networking was initially
`
`introduced in high end luxury class models (as with all leading-edge technology), but the standardisation efforts which
`
`followed helped to support the economy of scales necessary for its introduction into the mid-range and standard class
`Page 3 of17
`IEE_Draft_1.Doc
`
`Page 4 of 18
`
`

`
`vehicle. Today networked electronic subsystems are a vital element in all classes of vehicle and as can be seen from
`
`Figure 3iii this electronics presence in vehicles is growing rapidly.
`
`Automotive
`
`EDP
`
`Industrial
`
`Consumer Electronics
`
`Communications
`
`Aerospace
`
`0
`
`10
`5
`Compound Annual Growth Rate for
` European Semiconductor Consumption
`
`15
`
`20
`
`Figure 3 Semiconductor Consumption Compound Annual Growth Rate
`
`In the US the SAE (Society of Automotive Engineers) has published a series of documents describing recommended
`
`practices for vehicle networking. The SAE has also formally classified vehicle networks based on their bit transfer rates,
`
`Table 1 illustrates these categories. Specific standards exist for Class A, Class B and Class C networks, but the SAE
`
`have not yet defined specific standards for Class D networks. However networks which exceed a data rate of 1Mb/s are
`
`often referred to as Class D networks.
`
`Network Classification
`
`Speed
`
`Application
`
`<10 kb/s
`
`Convenience features
`
`Class A
`
`Low Speed
`
`e.g. trunk release, electric mirror adjustment
`
`10 – 125 kb/s
`
`General information transfer
`
`Class B
`
`Medium Speed
`
`e.g. instruments, power windows
`
`125 kb/s – 1 Mb/s
`
`Real time control
`
`Class C
`
`High Speed
`
`e.g. power train, vehicle dynamics
`
`> 1 Mb/s
`
`Multimedia applications
`
`Class D
`
`e.g. Internet, Digital TV
`
`Hard real time critical functions
`
`e.g. X-by-Wire applications
`
`Table 1 Classification of automotive networks
`
`A typical motor vehicle represents an extremely hostile environment for electronic equipment, subjecting this
`
`equipment to adverse conditions such as: mechanical vibration; temperature swings from –40 oC to +80 oC; splashes
`
`from oil, petrol and water; ice; strong electromagnetic fields (automotive field strengths can be > 200 V/m, domestic is
`
`Page 4 of17
`
`IEE_Draft_1.Doc
`
`Page 5 of 18
`
`

`
`around 3 V/m and industrial 10 V/m ); electrical spikes/transients of both polarities (> ± 100V); load dumps; jump
`
`starts; high humidity; dust; sand storms; and potential mis-wiring of electrical systems (e.g. short circuits to ground or
`
`positive, reverse battery, etc.).
`
`Along with the environmental considerations, automotive network solutions require some special design considerations,
`
`such as:
`
`(cid:216) High integrity
`
`The probability of an undetected error must be negligible for the life span of the
`
`vehicle
`
`(cid:216) Bounded determinism
`
`A guaranteed upper threshold on message latency time for control problems
`
`(cid:216) EMC compliance
`
`Both emitted radiation levels and the tolerated absorption levels must be met
`
`(cid:216) Low interconnection count Each additional connector increases the probability of a potentially life endangering
`
`fault
`
`(cid:216) Compact connectors
`
`The connector is often the largest component on an automotive electronic module
`
`(cid:216) Low cost
`
`Costs are critical. A saving of a few pennies on a component is substantial in high
`
`volume production
`
`(cid:216) Network composability
`
`Variations across models and after market extras require a network which is easily
`
`expand and modified
`
`(cid:216) Fault Tolerance
`
`Communication must be restored when faults are removed and redundancy is
`
`becoming important
`
`The typical vehicle will have more than one network system
`
`Electronic equipment is distributed throughout a modern vehicle supporting a host of functions as illustrated in Figure
`
`4. The functionality for a given automotive system is often distributed to span more than one network system. For
`
`example, the interplay between an engine management system network and the traction control system network needs to
`
`be carefully defined where, for instance, a reduction in engine torque is necessary to reduce drive wheel slippage,
`
`through fuel and engine timing adjustment. Another example is an intelligent auto-routing function, which might
`
`require information from a number of systems, gathering variables such as ABS wheel position data, steering wheel
`
`angle, GPS satellite data, and the radio RDS-TMC (Radio Data System - Traffic Message Channel) information.
`
`Page 5 of17
`
`IEE_Draft_1.Doc
`
`Page 6 of 18
`
`

`
`Figure 4 Electronic equipment in a modern motor car
`
`Automotive Network Solutions
`
`Table 2 shows a selection of automotive network solutions. There is a wide range of automotive networks reflecting
`
`defined functional and economic niches. High bandwidth networks are used for vehicle multimedia applications, where
`
`cost is not excessively critical. Reliable, responsive networks are required for critical real-time control applications such
`
`as powertrain control, and vehicle dynamics. In such demanding control applications the functional needs dominate
`
`over the economic ones and it is sometimes necessary to implement networks incorporating fail-safe redundancy.
`
`Comfort electronic systems such as power windows, adjustable seats and some instrumentation require only modest
`
`response times which only just surpass human perception times. Comfort systems are far more cost sensitive and the
`
`associated networks and modules are highly tuned to be cost effective. Certain vehicle functions may be implemented
`
`on a very minimalist network, supporting simple features, such as: trunk release and central locking, where delays in the
`
`order of a second are acceptable. Often single wire networks running at 10 kb/s are suitable here.
`
`Page 6 of17
`
`IEE_Draft_1.Doc
`
`Page 7 of 18
`
`

`
`Protocol
`
`Affiliation
`
`Application Media
`
`Bit
`
`Media
`
`Error
`
`Data Field
`
`MAX.
`
`Encoding
`
`Access
`
`Detection
`
`Length
`
`Bit Rate
`
`ABUS
`
`APC
`
`VW
`
`Ford
`
`Control
`
`Audio
`
`Single wire
`
`NRZ
`
`Contention
`
`Bit only
`
`16 bit
`
`Twisted pair NRZ
`
`CSMA/CA
`
`Checksum 64 bit
`
`500 kb/s
`
`9.6 kb/s
`
`AUTOLAN
`
`General Inst. Control
`
`Twisted pair API
`
`Master/slave CRC
`
`0 – 64 bit
`
`4 Mb/s
`
`BEAN
`
`CAN
`
`CCD
`
`CSC
`
`Toyota
`
`Bosch
`
`Crysler
`
`Crysler
`
`Control
`
`Control
`
`Single wire
`
`NRZ
`
`CSMA/CD
`
`Twisted pair NRZ &
`
`Contention
`
`CRC
`
`CRC
`
`8 – 88 bit
`
`10 kb/s
`
`0 – 64 bit
`
`1 Mb/s
`
`Stuffing
`
`Sensor Mux.
`
`Twisted pair NRZ
`
`CSMA/CR
`
`CRC
`
`Un-limited
`
`~7.8 kb/s
`
`Sensor Mux.
`
`Twisted pair Voltage
`
`Polling /
`
`__
`
`1 bit
`
`~1kb/s
`
`Addressing
`
`D2B
`
`Optical Chip
`
`Audio /
`
`Fibre Optic
`
`PWM
`
`Contention
`
`?
`
`?
`
`12 Mb/s
`
`Consortium
`
`Video
`
`DAN
`
`Alfa Romeo
`
`Dash Board
`
`Twisted pair NRZ
`
`Master/slave CRC
`
`Master/slave CRC
`
`8 bit
`
`16 bit
`
`DSI
`
`Motorola
`
`Sensor Mux.
`
`2 wire
`
`Voltage &
`
`Current
`
`9.6 kb/s
`= 5 kb/s
`
`Twisted pair
`
`PWM
`
`Polling
`
`Parity
`
`16 bit
`
`~27.8 kb/s
`
`IVMS
`
`Nissan
`
`J1850 PWM SAE
`
`J1850 VPW SAE
`
`J1939
`
`SAE
`
`Control
`
`Control
`
`Control
`
`Control
`
`2 wire
`
`1 wire
`
`PWM
`
`VPW
`
`CSMA/CR
`
`CSMA/CR
`
`Twisted pair NRZ &
`
`Contention
`
`Stuffing
`
`CRC
`
`CRC
`
`CRC
`
`?
`
`?
`
`CRC
`
`CRC
`
`8 – 64 bit
`
`41.6 kb/s
`
`8 – 64 bit
`
`10.4 kb/s
`
`0 – 64 bit
`
`1 Mb/s
`
`= 2048 bit
`
`110 Mb/s
`
`?
`
`25 Mb/s
`
`32 or 64 bit
`
`1 Mb/s
`
`128 bit
`
`2 Mb/s,
`
`4 Mb/s soon
`
`MML
`
`Delphi
`
`Multimedia
`
`Fibre Optic
`
`NRZ
`
`Master/slave
`
`MOST
`
`Most Co-op Multimedia
`
`Fibre Optic
`
`?
`
`?
`
`PALMNET Mazda
`
`Control
`
`Twisted pair NRZ
`
`Contention
`
`TTP
`
`TTTech
`
`Real Time
`
`2 channel
`
`MFM
`
`TDMA
`
`Control
`
`VAN
`
`Renault &
`
`Control
`
`Twisted pair Manchester
`
`Contention
`
`CRC
`
`0 – 64 bit
`
`~250 kb/s
`
`PSA
`
`Table 2 A selection of automotive networks
`
`Page 7 of17
`
`IEE_Draft_1.Doc
`
`Page 8 of 18
`
`

`
`Gateways and bridges are devices employed to interconnect multi-network architectures. Gateway devices can connect
`
`dissimilar networks whereas bridges are used to connect networks which have common data link layer protocols.
`
`Gateways and bridges can filter data passing between functionally independent network segments, allowing only the
`
`messages required by a module on another network segment to pass through. For example, if the trip computer requires
`
`the fuel tank level data in order to determine the optimum refuelling point, it can receive data, which may have
`
`originated on a Class A network node. This data may have travelled via a bridge to a Class B network and then via a
`
`gateway to a Class D network. Often diagnostic interfaces are optimally placed on gateway or bridge nodes for strategic
`
`traffic monitoring.
`
`Automotive control networks
`
`Conventional automotive control networks are widely used in control systems for applications such as engine
`
`management, door control, etc. These networks operate at moderate data rates (SAE Class B or Class C). The
`
`automotive system design engineer must consider the functional requirements in terms of information flow, network
`
`bandwidth and response times. The following issues will require specific consideration:
`
`(cid:216) Worst case network traffic load which includes: inter-network traffic; diagnostic data; etc.
`
`(cid:216) Individual message priority assignment
`
`(cid:216) Physical and Logical distribution of data sinks and sources
`
`(cid:216) Network expansion capacity for an entire range of vehicle models
`
`(cid:216) Error probability and its effects on traffic latency
`
`(cid:216) System level FMEA (Failure Mode & Effect Analyses) and fault tree analyses results
`
`(cid:216) Physical length constraints for network segments
`
`(cid:216) Fault tolerance behaviour and possible redundancy
`
`(cid:216) Optimum placement of bridges and gateways
`
`(cid:216) Network management control schemes and associated traffic
`
`Fortunately, the automotive industry has created and are adopting market-wide standards for vehicle control networks;
`
`in order to minimise production costs, through mass production. A global consensus on methods and implementations
`
`enhances the total product development cycle, ultimately impacting on the final cost to the consumer. CAN and J1850
`
`are currently two of the most successful standards for vehicle control networks.
`
`Page 8 of17
`
`IEE_Draft_1.Doc
`
`Page 9 of 18
`
`

`
`CAN – Controller Area Network
`
`In Europe the dominant vehicle control network is CAN (Controller Area Network). This protocol was developed by
`
`Robert Bosch GmbH in the mid 1980’s and was first implemented in a Mercedes Benz S-class car, in 1991. CAN has
`
`since been adopted by most major European automotive manufacturers and a growing number of US companies are
`
`now using CAN. In the US, in 1994, the SAE Truck and Bus Control and Communications subcommittee selected CAN
`
`as the basis for the J1939 standard (a Class C network for truck and bus applications). The ISO standardised CAN as an
`
`automotive networking protocol: ISO 11898 and ISO11519-2.
`
`Many of the world’s major semiconductor companies now offer CAN implementations. It is estimated that
`
`there are already over 140 million CAN nodes installed world-wide. [Although CAN was developed as a vehicle
`
`network standard, it is interesting to note that, currently, the majority of CAN applications exist outside of the
`
`automotive industry, employed in numerous other applications ranging from farm machinery to photocopiers.] CAN
`
`may be implemented as a Class A, Class B or Class C network.
`
`J1850
`
`In the US, the SAE adopted J1850 as the recommended protocol for Class A and Class B networks. This protocol was
`
`the result of a co-operative effort among the ‘Big Three’ car companies: GM, Ford, and Chrysler. The protocol
`
`specification is a combination of GM’s Class 2 protocol and Ford’s SCP (Standard Corporate Protocol). Emissions
`
`legislation was highly influential in the standardisation of J1850. The OBD-ll (On Board Diagnostics ll), created by
`
`CARB (California Air Resources Board) requires the implementation of diagnostic tools for emission-related systems.
`
`It specifies that stored fault codes should be available through a diagnostic port via a standard protocol, namely J1850
`
`and the European standard, ISO 9141.
`
`High bandwidth automotive networks
`
`Formula One competitions are not the only races in the automotive arena. The race to introduce an automotive
`
`multimedia network standard is well under way. It is just a matter of time before networked in-car PCs will become
`
`options or standard features in motor cars. Such PCs will provide a host of additional functionality for entertainment,
`
`navigation and business applications. A number of companies such as Microsoft, Saab, Mecel, Intel, Clarion and others
`
`are working on their vision of the street-computer for in-vehicle use, and have demonstrated their work in the Personal
`
`Productivity Vehicle. Meanwhile, IBM, Delco, Netscape and Sun Microsystems are developing the Network Vehicle
`
`which uses Java as its operating environment. The development of such in-car personal computers will support features
`
`such as:
`
`Page 9 of17
`
`IEE_Draft_1.Doc
`
`Page 10 of 18
`
`

`
`(cid:216) Voice activated control for many functions
`
`(cid:216) Internet access from the car
`
`(cid:216) Text to speech e-mail reading while you “drive and listen”
`
`(cid:216) Voicemail
`
`(cid:216) Auto-route planner with real-time updates using the traffic reports from your radio’s RDS or the Web
`
`(cid:216) Advanced interactive digital audio and video features
`
`(cid:216) Computer games and in-car-entertainment systems for the back seat passengers
`
`The emerging technology will allow the vehicle to become a true mobile office or a sophisticated gaming arcade, at the
`
`press of a button. However, the question of driver distraction and the associated effects on safety has yet to be resolved.
`
`A new class of vehicle network is emerging to connect the forthcoming in-car personal computers and their peripherals.
`
`The Optical Chip Consortium has specified a network called D2B (Domestic Digital Bus) which is a fiber optic based
`
`solution offering approximately 12 Mb/s of bandwidth. This network is currently used in the new Mercedes S-Class.
`
`Oasis Silicon Systems have developed the MOST (Media Orientated Systems Transport) solution, again with a fiber
`
`optic physical layer, giving a transfer rate of 25 Mb/s. Delphi Automotive Systems provide a solution in the form of
`
`MML (Mobile Media Link). Fiber optic based MML has an impressive transfer rate of 110 Mb/s.
`
`Toyota, GM, Ford, Daimler, Chrysler and Renault founded AMIC (Automotive Multimedia Interface Collaboration) in
`
`October 1998iv. AMIC represents a global project to standardise the vehicle multimedia architecture for the 21st century.
`
`The plug-and-play ‘infotainment’ specification will encompass software interfaces for vehicle systems, connectors and
`
`network implementations. Critical to this architecture are gateways and firewalls, preventing PC software (viruses, etc.)
`
`or malfunctions from interfering with the vehicle’s other control and data networks. There is a clear incentive for
`
`companies to have their technologies incorporated into the vehicle multimedia standards and Microsoft is making a
`
`significant effort with the Windows CE based Auto PC, unveiled in 1998. However, the automotive giants are
`
`determined to remain in the driving seat, and it is unlikely that they will uncharacteristically tie themselves to a single
`
`supplier from the onset. From a network perspective it is probable that an IDB-C (Intelligent Data Bus-CAN) solution
`
`will become one of the adopted standards. IDB-C is based on CAN’s physical and data link layers, but will be
`
`complemented by a higher speed multimedia bus, almost certainly based on fiber optic media, similar to the MOST or
`
`MML solutions. The in-car PC is expected to have a USB connection and a standard IrDA (InfraRed Data Association)
`
`port, leaving ample room for peripheral expansion and after market upgrades.
`
`Page 10 of17
`
`IEE_Draft_1.Doc
`
`Page 11 of 18
`
`

`
`Control by wire networks
`
`Networked electronic modules are replacing the equivalent mechanical systems! Electrical and electronic systems are
`
`eliminating power steering pumps, hoses, hydraulic fluid, drive belts, pulleys, and brake servos. Systems like E-Steer
`
`(Steer-by-wire) from Delphi Automotive Systems will be seen in high volume European vehicles later this yearv.
`
`X-By-Wire is an EU-funded BRITE-EURAM research project (contract number BRPRCT95-0032), which has
`
`resulted in the design of a novel computer architecture, TTA (Time-Triggered Architecture), which is bases on time-
`
`triggered technology for fault-tolerant distributed embedded real-time systems. Fundamental to this strategy is the
`
`communications protocol TTPvi (Time-Triggered Protocol), where channel access control is based on a TDMA (Time
`
`Division Multiple Access) scheme, derived from a fault tolerant common time base. Prof. Hermann Kopetz at Vienna
`
`University of Technology is the authority on this extremely well designed protocol, which has a bright future, not only
`
`in the automobile but also in the aerospace and rail industries. TTP it is extremely reliable and deterministic but
`
`somewhat less flexible than most other automotive control networks.
`
`TTA has defined a network architecture to replace the fore-mentioned mechanical systems, Figure 5 illustrates the
`
`concept. The replacement of mechanical systems with electronic solutions potentially offers several advantages:
`
`(cid:216) Less expensive in volume production
`
`(cid:216) Simplifies manufacturing of left hand drive and right hand drive vehicles
`
`(cid:216) Simplifies the general assembly of vehicles
`
`(cid:216) Intelligent self diagnosing systems, offering enhanced reliability and dependability
`
`(cid:216) Less mass, thus enhancing vehicle performance
`
`(cid:216) Environmentally compatible, no fluid necessary
`
`(cid:216) More compact
`
`(cid:216) Simplifies integration of auxiliary systems like active collision avoidance and cruise control systems
`
`Page 11 of17
`
`IEE_Draft_1.Doc
`
`Page 12 of 18
`
`

`
`The drive-by-wire concept is perhaps a little daunting at first, however, when one considers that we have been travelling
`
`in fly-by-wire controlled aircraft for many years now, drive-by-wire does not seem to be such a big step.
`
`Figure 5 Drive-by-wire
`
`Distributed software development for automotive systems
`
`The development of distributed real-time control software is a challenge for any engineering design team. The
`
`combined hardware and software solution needs to be arrived at in a cost-effective manner, which requires a formalised
`
`approach to design, prototyping and testing. To this end rapid prototyping methods are now being introduced into the
`
`development cycle for vehicle electronics. The emerging rapid prototyping based development cycle is initiated with
`
`the generation of a requirement analysis specification for the proposed system. A CASE (Computer Aided Software
`
`Engineering) tool assists in this analysis and leads into a computer aided design phase. The software design approach is
`
`moving towards an object oriented model and the challenges of creating large-scale distributed applications can be
`
`approached by using visual modelling tools such as UML (Unified Modelling Language). The output of such tools can
`
`be cross-linked to the engineering documentation activity so that both code implementation, textual specifications and
`
`system diagrams are combined as different views of the same system. As Figure 6 illustrates the conventional approach
`
`of path B is being replaced by the interactive method, path A. Automatic code generation from the specification
`
`representations of the system is now possible, often leading to pre-production quality software code. The resulting code
`
`must be tested in a hardware environment. Here perhaps the most powerful advances are being made. The prototype
`
`software can be executed on a variety of development platforms such as a VME hardware rack, Power PC platforms,
`
`PCs, or the actual target hardware. Configurable and scaleable operating systems allow the hardware requirements to be
`
`accurately assessed and quantified early in the design cycle. In fact, software development can be completed before the
`
`Page 12 of17
`
`IEE_Draft_1.Doc
`
`Page 13 of 18
`
`

`
`final hardware is completely designed. HiL (Hardware in the Loop) implementations are possible where the real time
`
`simulation is comprised of one or more components which exist as real hardware, while other components are simulated
`
`as mathematical models using tools such as Mathlab or Simulink.
`
`Design
`Specification
`
`A
`
`Design
`Specification
`
`Analyses
`&
`Design
`
`TEST
`
`Analyses
`&
`Design
`
`B
`
`TEST
`
`Implementation
`
`Implementation
`
`Figure 6 Software development cycle
`
`Software testing of the prototype implementation, using automated test sequences, dramatically cuts down on the
`
`otherwise repetitive testing which hitherto may have required actual trials in the car. Based on the evaluation of the
`
`implementation performance the loop iterates until ready to proceed directly to early target resident executable code.
`
`Because software has now been assigned such an important role in automotive systems, standardised software
`
`layers are being defined for vehicle networks. Such layers offer functionality such as operating systems, communication
`
`interface systems and network management systems. The recent developments in the area of OSEK/VDX provide a
`
`good example of such an approach.
`
`OSEK/VDX
`
`In May 1993, OSEK was initiated as a joint project by a number of companies within the German automotive industry.
`
`OSEK aims to achieve a standard open-ended architecture for distributed control units within vehicles. OSEK is an
`
`abbreviation for the German term “Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”. The
`
`English: equivalent is: “Open Systems and the Corresponding Interfaces for Automotive Electronics”. The French car
`
`manufacturers PSA and Renault were working on a similar project, the VDX-approach (Vehicle Distributed eXecutive),
`
`and they joined OSEK in 1994, giving rise to the OSEK/VDX standard. OSEK/VDX aims to specify a standardised
`
`interface to allow the gelling together of hardware modules, network protocols and application software in a co-
`
`ordinated and intelligent fashion.
`
`Page 13 of17
`
`IEE_Draft_1.Doc
`
`Page 14 of 18
`
`

`
`Underlying OSEK Operating System
`
`ISO/OSI Layers
`
`Application
`
`Communications API
`
`Network API
`
`Interaction
`Layer
`
`Network
`Management
`
`Network
`Layer
`
`Data Link Layer
`
`Bus I/O Driver
`
`OSEK/COM
`Standard API
`
`OSEK/COM
`Standard Protocols
`
`OSEK/COM
`Device Driver
`Interface
`
`Application
`
`Presentation
`Session
`Transport
`
`Network
`
`Data Link
`Layer
`
`Bus Communication Hardare
`
`Physical
`
`Bus Frame
`
`Network Media
`
`Figure 7 OSEK/VDX structural overview
`
`OSEK/VDX specifies a series of interfaces, which allows for the development of software components, which are
`
`portable and reusable. Figure 7 shows a structural overview of OSEK/VDXvii. The software application interface
`
`specification is abstracted from the hardware and the network involved. This concept is illustrated in Figure 8.
`
`Functionality is both configurable and scaleable, enabling optimum tuning of architecture and application. The
`
`specification facilitates functional verification and validation. Because the API (Application Programming Interface) is
`
`standardised, development on various platforms without the need to learn a new tool set is possible, resulting in a clear
`
`saving on development time. Software from different suppliers can now co-habitate within a single microcontroller.
`
`For the first time the potential for real co-operation between the various system suppliers is made possible,
`
`where traditionally products were developed independently, and rivalry rather than co-operation was the order of the
`
`day. Now those who hold the purse strings are changing the rules somewhat.
`
`Page 14 of17
`
`IEE_Draft_1.Doc
`
`Page 15 of 18
`
`

`
`C
`
`C++
`
`JAVA
`
`CAN
`
`APPLICATION
`
`SOFTW ARE
`
`PLATFORM
`
`NET W ORK
`
`OSEK
`VDX
`
`HARDWARE
`
`VAN
`
`J1850
`
`8 Bit
`Controller
`
`Power PC
`
`16 Bit
` Controller
`
`PC
`
`Figure 8 OSEK/VDX: Independence of the network, hardware and applications
`
`OSEK/VDX realises a distributed operating environment within the vehicle; based on the same principles used
`
`to implement distributed operating environments within large data networks. OSEK/VDX‘s ultimate goal is to reduce
`
`costs by enabling the creation of re-usable embedded application software. The PC industry has shown that once an
`
`adopted operating system standard is in place, products become far more commercially competitive.
`
`However, it is worth noting that the flexibility offered by the OSEK/VDX approach has some cost implications
`
`in terms of additional ROM, RAM and processor overhead. If OSEK compliant software implementations demand
`
`higher specification processors, then cost saving, in terms of software reuse, in the short term may be more than offset
`
`by additional hardware costs accrued over millions of unitsviii. Never the less, future silicon prices will decrease, and the
`
`benefits of reusable, mature and validated software, in the long term, is probably worth the initial investment.
`
`It is interesting to note that the aerospace industry has expressed considerable interest in the OSEK/VDX
`
`developments, viewing it as a potential solution to their similar problem set.
`
`Page 15 of17
`
`IEE_Draft_1.Doc
`
`Page 16 of 18
`
`

`
`Conclusions
`
`Vehicle networks were invented by necessity to resolve the problems associated with bulk wiring harnesses. However,
`
`the coming of automotive networks has opened up new opportunities for the industry. Control networks are now well
`
`established in high-end vehicles and are quickly filtering down to all vehicle classes.
`
`Whereas control networks operate behind the scenes, as far as the driver and passengers are concerned, it is the
`
`high bandwidth multimedia networks, wh