Post a Comment
Feature
From EDN Europe: Drive by wire fuels network-highway race
New automotive subsystems promise greater than 20% fuel economy with safety and ride-comfort enhancements. Control-system engineers scour network highways for the optimum balance of real-time performance, security, and cost.
By David Marsh, Contributing Technical Editor -- EDN, 4/13/2000
Automotive design is preparing for its biggest change since
the auto industry discovered semiconductors. Continuous demands for fuel
efficiency mandate "drive-by-wire" systems that eliminate power-sapping belt
drives and pumps and substitute electrical subsystems for mechanical links.
Electric brakes will replace hydraulics, increasing safety, lowering operating
cost, and dispensing with environmentally hazardous fluids. Steering columns
will disappear, immediately improving driver safety and making it easy to
package left- and right-hand drive models. Engine- and power-train-control
systems will become more tightly coupled within an architecture that enhances
vehicle stability and ride comfort, combining elements such as active braking,
steering, and suspension control.
Such systems must support hard real-time control in a safety-critical environment. Of course, degrees of real-time control and safety exist, and engineers must select systems that provide acceptable performance at reasonable cost. Initially targeting military jets, many airplanes employ fly-by-wire control systems that are designed to be as safe as possible, almost regardless of cost. But this approach is prohibitively expensive for the auto industry; the bottom line is that any new system must be at least as safe as the one it replaces. First off the block, brake by wire is now set to appear in passenger cars (Figure 1). Automotive industry insiders predict that the system may appear as soon as 2002 in a BMW Series-7 model.
The key element that facilitates drive by wire is the in-car network. But which topology will emerge as the technology leader? And will vehicles carry only one type of network? BMW officials think the answer to the first question is its proprietary "byteflight" system. The company is developing the protocol, which was formerly called the safety-integrated (SI) bus protocol, with Motorola. But the Society of Automotive Engineers' (SAE) Congress 2000 program suggests that the answer may lie with technologies whose inner workings are already in the public domain: ISO 11898-standard controller- area network (CAN), and time-triggered architecture derivative Time Triggered Protocol (TTP) (Reference 1). Each of these technologies has the potential to complement the others, so vehicles may carry a mixture of network designs.
Networks naturally divide in two
In a typical in-car-network topology, the distributed system comprises subsystems (or clusters) that communicate across a serial bus (Figure 2a). Each cluster accommodates a set of related functions, such as controlling the power-train or body electronics. Coordination and safety requirements suggest a natural division: Power-train components require tight coordination among throttle, transmission, and braking systems and have high, intrinsic safety requirements. Body electronics require relatively loose coupling for functions, such lighting systems and other comforts, and have comparatively relaxed safety requirements. Accordingly, many designers divide the network in two, typically communicating via a bridge (or gateway) device. Vehicle packaging requirements frequently dictate a deviation from a linear topology, so practical systems must tolerate short stubs or, ideally, accommodate both linear and star configurations.
Each device (or node) in a cluster comprises a physical-layer interface, a communications controller and network-layer interface, the host CPU and its application software, and an I/O interface and channels (Figure 2b). The device's host computer typically runs an embedded real-time operating system (RTOS) that may comply with the OSEK (open system and corresponding interfaces for automotive electronics) specification, allowing designers to use object-oriented software-development techniques that promote software reuse to shorten the development cycle (references 2 and 3). The current Version 2.1 of the OSEK RTOS specification also provides guaranteed determinism within the device. It ensures that the device responds to events in the correct order and in a timely manner. The real challenges start when a device—especially within the power-train cluster—wants to communicate.
The two main approaches to real-time-system design rely on event or time triggering to control system actions. Schemes such as BMW's byteflight accommodate both techniques, but the event/time differentiation characterizes today's CAN protocol and TTP. The communications system must reliably exchange error-free messages on time, accommodate transmission failures, and avoid the "babbling-idiot" syndrome that results when a faulty device monopolizes the bus. Desirable attributes include guaranteed determinism, which means the system always performs the correct operations in the correct sequence; composability, so you can integrate subsystems without affecting timing issues you calculate during design; and flexibility, so you can easily add or change configurations. Finally, the system must be safe; foreseeable hardware failures must not endanger life.
Multiplexing targets real time
Today's de facto standard for automotive multiplex wiring, CAN, took to the road in 1991 in a Mercedes Benz S-class model. Designed by automotive-component supplier Bosch, CAN's initial application was to simplify in-vehicle wiring; the wiring harness is traditionally an automobile's most complex and expensive electrical system component. But the potential for linking and controlling distributed-computing functions is now even more important than saving complexity and weight. Volvo's S80 automobile, for example, saves more than 1 km of wire with a 250-kbps CAN powertrain-control bus linked to a 125-kbps CAN body-electronics bus to manage 18 electronic-control units (ECUs).
Traditional CAN networks are event-triggered systems that struggle to meet today's most stringent real-time requirements. To guarantee responsiveness, early systems limited bus traffic to around 10% of potential capacity. Devices communicate directly with others in a multimaster, broadcast topology. The frame format includes a header with an 11-bit (optionally, 29-bit) device identifier, 1 to 8 data bytes, and cyclic-redundancy-check (CRC) error-checking and -acknowledgement fields (Figure 3a). Bus arbitration relies on a nondestructive carrier-sense multiple-access/collision-avoidance (CSMA/CA) technique with message priorities that device-unique identifiers set. Devices with data to send wait for the bus to become idle before transmitting their identifiers. The physical layer employs negative-true, wired-OR logic with the device identifier first transmitting the most significant byte (see sidebar "Joining the dots"). If two devices simultaneously transmit, the arbitration algorithm guarantees that the device with the most "dominant" levels (the lowest numeric value, thus the highest priority) wins. When a receiver correctly receives a message, it sets the second acknowledgement field bit "true," so the sender knows that at least one receiver has a copy of the message.
Given 100-bit average transmission packets, message latencies can span 100 msec to 250 msec for a 1-Mbps CANbus system. This wide latency range, or latency jitter, may concern designers. Excessive latency jitter degrades the responsiveness of a real-time system and can create "orphans," in which a receiver misses a message due to timing out before the message arrives. Orphan messages degrade system performance because they do not deliver timely data, and you must handle them carefully to avoid compromising system integrity. But schedulability analysis work by Ken Tindell and Alan Burns and others has proved that CAN suits real-time automotive applications (Reference 4). The latency for the highest priority message on the Volvo S80's 250-kbps bus is typically 400 to 800 µsec. Such analysis is valid only for a well-defined target, accounting for parameters such as maximum frame length and arbitration time. In the worst-case scenario, the highest priority message waits for the longest message to complete and then arbitrates among all other devices that subsequently and simultaneously request bus access.
How the controller IC handles bus transactions is another critical factor. Architectures such as Motorola's msCAN controller provide hardware assistance with internal arbitration logic that ensures competing messages from the device always appear in the correct order. The msCAN controller has three on-chip transmission buffers with 8-bit priority tags that load the IC's output-message queue according to priority. OSEK-compatible operating systems, such as Realogy's SSX5 and its Time Compiler analysis tool, allow you to accurately calculate time bounds for your system's response and guarantee fully deterministic system behavior.
CANbus communications are highly reliable. The CAN 2.0 protocol specification shows that the likelihood of an undetected transmission error is less than the transmission-error rate ×4.7×10-11 (Reference 5). Or, to put it another way, the likelihood of an undetected transmission error in a vehicle's antilock-braking system is about one instance per 1000 years. CAN's main error-handling mechanism is a transmission retry. A device that detects an error transmits an error-flag sequence of six consecutive dominant bits, which violates the protocol's bit-stuffing rule that maintains receiver lock by limiting runs of "0" or "1." In normal error-active operation, other devices interpret the error flag as an error and transmit their own error flags, so the sequence length can increase from 6 to 12 bit times. The original transmitter then retries. To help avoid babbling-idiot failures that monopolize bus traffic, CAN controllers maintain internal error counters; if the error count exceeds a threshold value, a device considers itself faulty and suspends its transmissions.
Using CAN's SAE J1939 derivative, an evaluation by the US National Highway Traffic Safety Administration recorded no failures in 71 million transmissions during a 4000-km trip, despite the administration's engineers' purposely loading the CAN bus to capacity (Reference 6). The average bus traffic across the test vehicle's power-train-to-body electronics bridges was approximately 500 messages/sec, increasing to about 600 messages/sec during gear changes. The report estimates the system's capacity at about 1600 messages/sec using a 250-kbps link and observes no failures in more than 1 billion J1939 messages.
TDMA tackles tight time lines
Another technique for adapting a serial channel for time-critical messages dispenses with CSMA/CA arbitration in favor of a time-division multiple-access (TDMA) strategy. Researchers took this approach with European Union-funded research projects into time-triggered architectures that culminate in the X-By-Wire Consortium's final report (Reference 7). This work is now in its commercial-realization stage; Austrian start-up TTTech is the major software and development-tool vendor. TTTech is focusing on TTP class C (TTP/C), which refers to the SAE's class-C definition for networks running at 125 kbps and faster (Reference 8); a lower cost Class A derivative is also available. Hardware support comes from Austria Mikro Systeme's AS8201 controller IC, and a second version is under way. ARM and Motorola are also designing silicon.
In a TTP/C system, devices carry two autonomous communication channels. The communications controller decouples the host CPU from the network, exchanging messages with other devices according to a static schedule. The dual-channel topology provides redundant operation; it preserves system integrity as long as one channel successfully receives a message. Ideally, the two independent buses take different routes around the vehicle to minimize the likelihood of wiring failures. Dual-channel replication is possible only because TTP/C is "replica determinate," which means that, for the same input data and internal state, all devices in a set produce the same output data at exactly the same time. TTP/C further exploits this property, with critical nodes employing fault-tolerant units built from replicated devices (Figure 4). Devices participate within a majority-vote system that forces a faulty device's communications controller to "fail silent" and thus avoids the babbling-idiot syndrome. A properly configured TTP/C cluster tolerates a single, permanent hardware failure.
System synchronization relies on a global clock that combines an ensemble of local device clocks. Devices synchronize to this global clock during system start-up and update their local clocks during normal system operation. Each device schedules transmission and reception according to a dispatching table, or message-descriptor list (MEDL), which you establish during system design. MEDL entries comprise time, address, and attribute fields; the depth of the table corresponds to the number of transmission messages in the cluster cycle (Figure 5a). Each communications controller within a cluster has its own copy of the MEDL, so every device knows when to transmit and when to receive.
Each device has a unique transmission slot within a TDMA "round" to transmit one message. A round is a short sequence of transmission slots that typically lasts 1 to 5 msec; any device that doesn't transmit during a round is suspect. Few devices need to update measurement data at this rate, so you distribute data exchanges over multiple rounds. Although message exchanges vary among rounds, each round's cycle time remains constant and dictates the maximum retransmission rate. Each round comprises a number of initialization (I) frames, normal (N) frames, or both. An I frame comprises a start-of-frame bit; a 4-bit header with 1 bit to signal an I or N frame and 3 bits to request mode changes; 0 to 128 data bits that carry controller state (C State) information; and a 16-bit CRC field (Figure 5b). A normal frame has a format identical to that of an I frame but carries data rather than C State information. A full cluster cycle comprises the sequence of rounds before the cluster's operation repeats itself.
Devices that periodically transmit I frames maintain system synchronization. A device that synchronizes itself sets its internal state to the C State it receives. The C State comprises the global time, the current index into the MEDL table, and a membership vector. The membership vector is a unique bit position that you assign to each device during system design. The protocol sets this bit "true" if the device successfully sends its message in the last round. One interesting feature is the system's ability to accommodate mutually exclusive system conditions via the mode-change bits. A mode change permits the system to dynamically reconfigure itself to suit current operational requirements, such as when switching between highway and off-road use. Importantly, a device can change mode only when an entry in the MEDL authorizes it. The communications controller controls the MEDL; the host CPU can directly access it. In effect, the communications controller provides a firewall against temporal and control errors.
CAN fights back with TTC
The open-system, license-free CAN community is working to adapt the system to stricter real-time needs. Holger Zeltwanger, director of CAN in Automation (CiA), reports that work began in January on a new session layer in that will permit time- and event-triggered communication over the same bus (Reference 9). You can already use the CAN open-software profile for low-speed drive-by-wire applications, but the new time-triggered CAN (TTC) system will provide basic hardware support for high-speed applications (Reference 10).
Each TTC-compatible device will require a timebase and a 16-bit time-capture register for incoming frames. These features will allow the device to transmit at a predetermined time and receiving devices to store and verify that time. A single-shot option will disable automatic retransmission after an error to guarantee that the time-triggered message doesn't compete for bus access.
Zeltwanger notes that "using TTC requires additional specifications, but these are related to higher layer protocols." Such protocols are yet to be developed and will differ among application fields. Zeltwanger hopes to present preliminary TTC results at Detroit's Convergence 2000 exhibition this September.
TTC communications will require the system to synchronize devices; today's CAN has no global clock, although such clocks are easy to implement (Reference 11). Tindell observes that several ways exist to eliminate frame-arrival jitter:
"For example, the receiving node need not pass the message to the application until a minimum time has passed," he says. He adds that clock synchronization can eliminate jitter by "acting only on the message at a set, coordinated time." Tindell notes that some CAN hardware already provides the foundation for implementing a global clock with submicrosecond accuracy. Motorola's msCAN controller has an option to latch a free-running timer when the state machine sees the "start-of-frame" bit. Motorola's TouCAN and Hitachi's HCAN designs have similar features, and various NEC KO-series CAN microcontrollers directly support TTC's hardware requirements.
The next turn
This article can provide only an overview of the complex, sophisticated CAN and TTP systems. For more information, request the full specifications from CiA and TTTech (see sidebar "For more information"). Each system's features suggest different roles: traditional CAN for real-time systems with "soft" timing requirements and TTP for "hard," tightly coupled clusters. TTP also has superior fault tolerance that suits mission-critical applications, such as brake by wire, at a somewhat greater cost than CAN. But CAN is flexible and more easily accommodates changes. With TTP, every time you add or significantly change a device, you must reprogram and reverify the scheduler. Both systems support structured development methods with varying third-party tool-set availability. Also, notice that the increase in a vehicle's electrical-system loading that electromechanical subsystems introduce mandates a change to higher voltage operation (see sidebar "Vehicles need more volts").
But no system yet dominates drive-by-wire applications, and a lot of development will come from both time-triggered CAN and TTP. Also, watch out for developments from BMW's byteflight. (By press time, BMW should have information available at www.byteflight.com.) BMW's plastic-optical-fibre system combines synchronous and asynchronous bus traffic within a star topology that's optimized for vehicle safety (Figure 6). Wilhard von Wendorff, PhD, senior automotive-system engineer at Infineon, explains, "Failure tolerance requires a distributed concept based on multiple electronic systems, all of which are synchronized." He says "The byteflight architecture not only increases performance and improves safety but also increases design flexibility and reduces cost." He adds that single events cannot cause system malfunctions, because you implement control across multiple locations and technologies within an architecture that defined object boundaries protect. Infineon has transceiver silicon that complements Elmos' stand-alone byteflight controller and star-coupler chips and Motorola's HC12BD32 byteflight CPU.
Meanwhile, Steve Evans, vice president of ARM Europe, says that ARM believes that "In the same way as CAN has become the de facto standard for automotive multiplex wiring, TTP will become a standard for hard, real-time, safety-critical applications." Evans notes the potentially complementary roles for CAN and TTP, observing that an ARM semiconductor partner has already developed an ARM-powered microcontroller that can bridge CAN to the French multiplex system, VAN (vehicle-area network).
Tindell adds, "CAN is flexible enough to mix time- and event-triggered messages, both with tight latency bounds. Market maturity and today's integration leads some silicon vendors to consider babbling-idiot avoidance techniques in hardware that I proposed in 1995. So you might see CAN surviving in the auto industry for quite some time yet!"
| Like controller-area-network (CAN) protocols, the Time Triggered Protocols (TTPs) specify no physical-layer medium. But although automotive CAN systems employ transceiver ICs that meet the ISO-11898 physical-layer CANbus specification, no standard exists for TTP, which may use CAN's physical layer for widespread deployment (Reference A). CANbus transmission levels are nominally 0, 2.5, and 5V on a differential bus. Levels of 0V on the CAN_L wire and 5V on the CAN_H wire signal a "dominant" (true) state; a level of 2.5V on both wires signals a "recessive" (false) state. The differential-bus scheme provides good EMC immunity and tolerates the ground shifts that typify automotive installations. Critically, the bus still works if one wire fails; performance degrades gracefully, providing "limp-home" capability. CANbus transmission speed is limited to allow each bit to stabilize on the network before another bit transmits. The 1-Mbps maximum value corresponds to a maximum network length of about 100m. TTP requires message synchronization but no bit synchronization, so it avoids this restriction. However, both protocols can run at high speeds over optical-fibre links. Designers strive to guarantee the real-time response they need at the lowest bus speed over copper cabling. This approach minimizes EMC generation and the need for expensive shielded cabling. Advances in transceiver design also help minimize EMC; Philips fabricates its forthcoming TJA1050 in a silicon-on-insulator (SOI) process that cuts emissions by more than 20 dB over the company's earlier processes. Other CAN semiconductor vendors include Dallas, Hitachi, Infineon, Intel, Micronas Intermetall, Motorola, National Semiconductor, NEC, Oki, STMicroelectronics, Texas Instruments, and Toshiba. Development tools are available from vendors such as Motorola, and support is available from EMS, IAR Systems, Ixxat Automation, Softing, and Vector Informatik. The latest IC trend is dual-CAN controllers for bridge-device applications. Patrick Leteinturier, director of automotive-systems definition at Infineon, explains: "Dual-CAN controllers provide an automatic link between power-train-and- body-electronics clusters." He says that the hardware takes care of message filtering and differing transmission rates to optimize bridge traffic, requiring little effort from the system designer. Infineon will include a stand-alone dual-CAN controller within its TC1775 Audo microcontroller, which is available for sampling. It's too early for widespread TTP-silicon availability. The AMS reference design uses the company's AS8201 controller and two Maxim Max1487 RS-485 transceivers. Despite its immaturity, TTTech has amassed support from giants such as ARM and Motorola, and new silicon is scheduled for the end of this year. Georg Stoeger, senior technical engineer at TTTech, says that three physical-layer configurations have run TTP/C to date. These comprise high-speed CAN, using Philips 82C250 line drivers with 120W shielded and unshielded twisted-pairs at speeds as high as 2 Mbps; RS-485 lines, also as fast as 2 Mbps, with the possibility of speeds to 10 Mbps; and a star-topology optical configuration that targets high-speed automation and aerospace. Stoeger notes, "The industry is currently researching suitable physical layers for safety-critical buses. But the possibility of using TTP/C over a CAN physical layer looks interesting, as it is inexpensive and well-known. But optical has supporters, too." TTTech provides development tools that you can evaluate with demo versions from the company's Web site. Third-party tool sets from Diab-SDS will support Motorla's TTP products, and Keil will support TTTech's TTPos operating system on Infineon's C166/167 processors. REFERENCE
|
| Electrical-system loads are approaching a practical maximum in many of today's vehicles. New technologies, such as brake by wire, electromechanical valve-train actuation, electric power steering, and electrically heated catalytic converters, will dramatically increase electrical power consumption. But these advances promise to slash overall power consumption (and thus improve fuel economy) by eliminating camshafts, belt drives and pumps, and a great deal of unnecessary weight. Automotive designers estimate that electrical valve-train operation (of the engine's inlet and exhaust valves) alone provides a 15% improvement in fuel consumption. Such operation also permits much tighter combustion control to reduce emissions without degrading vehicle performance. Electric steering provides another 2 to 5% saving. Electrically operated brakes respond twice as fast as hydraulic brakes and make it easy to implement antilock systems that actively distribute braking forces among the wheels. An electromechanical valve-train requires about 2 kW, four-wheel brake-by-wire disc brakes require another 4 kW, and electric steering needs about 500W. The electrically preheated catalytic converters that reduce start-up exhaust emissions by 60 to 80% require another 2 kW. Running these components at 12V requires large currents and huge increases in cabling thickness, so designers propose increasing the vehicle's operating voltage to nearly the maximum voltage that is considered safe from a shock-hazard viewpoint. The alternator will combine with the starter motor and become part of the flywheel assembly, further cutting power-transmission losses and providing a regenerative braking effect (Figure A). Assemblies that contain electronics will continue to use a 12V supply along with components such as tungsten-filament light bulbs, which dislike high voltages. Designers are investigating methods of maximizing efficiency and minimizing cost increases. Dual-voltage systems may comprise one alternator and a 36V traction battery to feed high-power loads, coupled to a 12V bus and reservoir battery by a step-down dc/dc converter. Batteries are relatively cheap, but dc/dc converters cost 50 cents to $1 per watt and can be too expensive for some automotive applications. A lower cost—but perhaps less energy-efficient—option substitutes a dual-voltage alternator for the dc/dc converter. You can evaluate systems today including core components, such as brakes, steering, electromechanical-valve-train, and combined starter-alternator assemblies. Ralph Heinrich, press officer at Siemens Automotive, reports that the company's 36/12V starter/generator will reach volume production by the second quarter of 2002. Heinrich observes that Siemens' combined starter/generator reaches a peak output of 8 kW with a efficiency of more than 80% across the entire speed range. He notes that a conventional generator outputs 1.5 kW with a maximum efficiency of 70%, which drops to 30% at high speeds. |
| For more information... | ||
| For information on subjects discussed in this article, contact the following manufacturers and let them know you read about their products in EDN Europe. | ||
| Bosch +49 7121 35 1628 www.bosch.com Circle No. 351 | BMW +49 89 3820 www.bmw.com Circle No. 352 | CAN in Automation (CiA) 1-888-217-8253 www.can-cia.de Circle No. 353 |
| Diab-SDS 1-650-356-5400 www.diabsds.com Circle No. 354 | EMS +49 8441 490260 www.ems-wuensche.com Circle No. 355 | IAR Systems 1-415-765-5500 www.iar.com Circle No. 356 |
| International Organization
for Standardization (ISO) +41 22 749 01 11 www.iso.ch Circle No. 357 | Ixxat
Automation +49 751 56146 0 www.ixxat.de Circle No. 358 | Keil
Elektronik 1-972-312-1107 www.keil.com Circle No. 359 |
| National Highway Traffic
Safety Administration 1-202-366-0123 www.nhtsa.dot.gov Circle No. 360 | PLS Programmierbare +49 35722 384 0 www.pls-mc.com Circle No. 361 | Realogy +44 1904 435129 www.realogy.com Circle No. 362 |
| Siemens Automotive +49 941 790 5000 www.siemens.de/at Circle No. 363 | Society of Automotive Engineers (SAE) 1-724-776-4841 www sae.org Circle No. 364 | Softing Automotive Electronics +49 89 456 56420 www.softing.com Circle No. 365 |
| TTTech +43 1 585 34 34 0 www.tttech.com Circle No. 366 | Vector Informatik 1-248-449-9290 www.vector-informatik.de Circle No. 367 | Volvo Car 1-800-458-1552 www.volvocars.com Circle No. 368 |
| Semiconductor vendors | | |
| ARM 1-408-579-2200 www.arm.com Circle No. 369 | Austria Mikro Systeme 1-408-345-1790 www.amsint.com Circle No. 370 | Dallas Semiconductor 1-972-371-4000 www.dalsemi.com Circle No. 371 |
| Elmos +49 231 754 90 www.elmos.de Circle No. 372 | Hitachi 1-800-448-2244 www.hitachi.com Circle No. 373 | Infineon Technologies 1-408-501-6000 www.infineon.com Circle No. 374 |
| Intel 1-801-763-2200 www.intel.com Circle No. 375 | Maxim Integrated Products 1-408-737-7600 www.maxim-ic.com Circle No. 376 | Micronas Intermetall 1-408-526-2080 www.intermetall.de Circle No. 377 |
| Motorola Semiconductors +44 1 35 35 5155 www.mot-sps.com Circle No. 378 | NEC Electronics Europe 1-408-588-6000 www.necel.com Circle No. 379 | National Semiconductor 1-408-721-5000 www.national.com Circle No. 380 |
| Oki
Semiconductor 1-408-720-1900 www.okisemi.com Circle No. 381 | Philips Semiconductor 1-408-991-3230 www.semiconductors.philips.com Circle No. 382 | STMicroelectronics 1-256-895-9544 www.st.com Circle No. 383 |
| Texas Instruments 1-972-644-5580 www.ti.com Circle No. 384 | Toshiba 1-212-596-0600 www.toshiba.com Circle No. 385 | |
Author info
You can reach Contributing Editor David Marsh at forncett@compuserve.com.SAE Congress 2000, March 6 to 9, 2000, Detroit, MI, www.sae.org.REFERENCE
1.www-iiit.etec.uni-karlsruhe.de/~osek/.
2. Marsh, David, "Automotive design sets RTOS cost and performance challenges," EDN Europe, September 1999, pg 32.
3. Tindell, K, and A Burns, "Guaranteeing message latencies on Controller Area Network (CAN)," University of York, 1994, ftp://ftp.cs.york.ac.uk/pub/realtime/papers/ICC_TB_Sept_94.ps.Z.
4. "CAN specification 2.0 parts A and B," CAN in Automation, www.can-cia.de.
5. "Development, evaluation, and demonstration of a tractor-trailer intelligent communication and power link," DOT HS 808865, January 1998, www.nhtsa.dot.gov/people/perform/its/TruckMux/html/truckmux.html.
6. "X-by-wire: Safety related fault tolerant systems in vehicles," XByWire-DB-6/6-24, Nov 24, 1998.
7. "Class C application requirements-J2056/1," SAE Handbook, SAE Press, 1994, www.sae.org.
8. International Organization for Standardization, ISO TC22 SC 3 WG 1, Task Force 6.
9. "CANopen specifications," CAN in Automation, www.can-cia.de.
10. Gergeleit, M, and H Streich, "Implementing a distributed high-resolution real-time clock using the CAN bus," http://borneo.gmd.de/RS/Papers/CAN-clock/CAN-clock.html.
