Vehicles will be home for some of the most diverse network and multiprocessing technology over the next five years. Standards will help improve acceptance and reduce costs, but the competitive nature of the industry limits the scope of hardware and software standards. Interchangeable computer-related components will probably remain manufacturer-specific for some time, with the exception of consumer-replaceable multimedia and communication components.
Leading the standardization charge for networks in automotive environments is the Controller Area Network (CAN) with OSEK/VDX (German for Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug/Vehicle Distributed eXecutive) providing a standard for real-time operating systems for the many embedded processors found in automotive networks. Both actually are well established standards, but their use is only in the beginning stages. They can be found on today's luxury cars and trucks, where computer-controlled and networked services are common.
CAN isn't the only kind of network found in automobiles. At the low end, the Local Interconnect Network (LIN) is being employed. A variety of multimedia networks are undergoing evaluation too, including a modified version of the IEEE-1394 standard to allow operation in a more hostile environment, the automobile.
In addition, software standards are becoming important in vehicle software development because of the need for high reliability and efficient development. OSEK/VDX isn't the only software initiative. Motor Industry Software Reliability Association (MISRA) C and Embedded C++ are standards designed to improve overall application development. C and C++ are languages of choice, with the assembler still filling in for low-end microcontroller development. Some of these standards target the automotive industry, but all are applicable to embedded application development.
All vehicles will eventually be extensively networked, making them more complex than any home and most office networks. The number of embedded networked processors also will be very high in vehicles. Dozens of processors will handle everything from car locks to braking control.
Automotive networks and software are undergoing customization for their target environment, yet the employment of this technology is for more than vehicle command and control. Today, CAN networks appear in various applications, from robotics to medical equipment. CAN's flexibility, low cost, and standardization make it an ideal alternative to more expensive networks, such as Ethernet.
Europe leads in the incorporation of standards-based operating systems and network protocols in their luxury models with about a two-year lead over American and Japanese models. This is due more to the momentum of existing technology than technical expertise.
Many American automobiles are networked using the 41.6-kbit/s J1850 standard. Unfortunately, J1850 has turned into three relatively unique implementations. J1850-based component use is consistent within each automobile vendor's product line, but not between vendors.
The American migration to CAN and the inclusion of other network technologies like LIN is expected to proceed in an incremental fashion with CAN, and sometimes LIN, replacing J1850.
Automotive Networks Even today, automobile networks are hierarchical in nature with multiple segments. Partitioning is done for a variety of reasons, from network segment bandwidth considerations to reliability and firewall considerations.Automotive systems can operate independently if network or gateways fail. This lets vehicles continue operation in a degraded capacity when failures occur.
Redundant networks aren't presently employed, but this may change over the next 10 years as X-by-wire comes into play. The term X-by-wire covers network control of critical systems, like steering and braking. Airplanes have employed X-by-wire for years, with redundant systems keeping planes flying at full capability even when some faults happen. This level of reliability is necessary before consumers will consider buying high-tech automobiles.
How might networks be distributed throughout an automobile? A typical automobile in 2005 should have half a dozen different kinds of networks and three times that many network segments (Fig. 1). This is a remarkable level of complexity, but it's one that will be designed for low cost and high reliability. In general, automotive networks can be grouped by purpose, such as control, X-by-wire, and multimedia.
A Harbinger Of Things To Come The new Mercedes Benz C and S Class models offer a look at things to come. Mercedes Benz's in-vehicle CAN network supports features like Automatic Slip Control and Electronic Stability Program. These communicate with a number of different subsystems including braking, the differentials, and the engine. A fiber-optic network is used for cell-phone and audio features.
Mercedes Benz is moving toward X-by-wire technology with its throttle boost and brake assist. The throttle boost augments the acceleration when the gas pedal is depressed. On the other hand, the brake assist increases the braking pressure based on the acceleration of the brake pedal. A quick depression of the brake pedal, to avoid an accident for instance, causes a power boost to the brakes. So, the car stops more quickly.
The J1850 standard with its various implementations is one of the most common automotive control networks in the U.S. It's shown in relationship to other networks like CAN and LIN in the table.
CAN is a midrange protocol definition that can be utilized with many different physical layers. CAN and LIN products are available from companies such as NEC, Microchip, Motorola Semiconductor, Delphi Automotive, and Philips Semiconductors. Microchip's PIC18Cx58 CAN controller and PIC16C43x LIN controllers are examples of integrated transceivers and microcontrollers designed to lower costs.
CAN, a Carrier-Sense-Multiple Access by Collision Detection using Arbitration (CSMA/CD-A) protocol, can operate at speeds up to 1 Mbit/s when the network is less than 30 meters long. By reducing the speed to 10 kbits/s, the maximum distance grows to 5000 meters. Regardless, CAN has a multimaster architecture with prioritized messages of 8 bytes or less, plus a 15-bit cyclical redundancy check (CRC).
Eventually, CAN will replace J1850, although a plethora of CAN-related specifications exist. For instance, the Society of Automotive Engineers' (SAE's) J2284 is a physical interface standard for high-speed CAN networks. SAE's 2411 is a single-wire CAN design presently implemented by General Motors. The tradeoffs with a single-wire approach are lower speed and a lower maximum segment length compared to a two-wire approach.
The ISO 11989 standard is a high-speed CAN definition while the ISO 11519 standard addresses low-speed CAN implementations. In the U.S., designations of CAN A, B, and C are used for low-speed (33.33 or 83.33 kbit/s), medium-speed (250 kbit/s), and high-speed, applications. Designation C is primarily employed in auto-body electronics, possibly in conjunction with LIN. CAN B is being utilized with the IDB-C multimedia specification of the IDB Forum. (These types of networks are discussed later.)
The CAN 2.0 protocol was chosen by the SAE Truck & Bus Control and Communications Network Subcommittee of the Truck & Bus Electrical Committee. It supports the subcommittee's "Recommended Practice for Serial Control and Communications Vehicle Network Class C," called the SAE J1939 specification.
Designer Defines The Message Although CAN is a sophisticated definition, it leaves the definition of message-content up to the designer. This means that most CAN implementations will be unique to a particular vendor. The ISO 15765 standard (or Diagnostics on CAN) is currently the only cross-vendor protocol standard. It's used in the U.S. to handle standard emissions testing.While CAN is designed to be inexpensive, LIN is even cheaper than CAN or J1850. But its lower speed and master/slave architecture means that CAN will be used for low-speed control services. These applications include door controls, climate control, seat adjustment, and steering-wheel mounted controls.
A recent definition, LIN has a protocol specification as well as an application programming interface (API) and a single-wire physical-layer specification. Implementations don't require a crystal, further reducing cost. But LIN is designed for a limited distance. LIN network segments are typically found in car doors or dashboards.
Another low-end network definition is Time Triggered Protocol/A (TTP/A). Its faster cousin, TTP/C, is designed for X-by-wire networks. TTP/A is comparable to LIN. It has some technical advantages, whereas LIN enjoys significant vendor support.
CAN, LIN, and TTP/A will remain in new vehicles for at least the next five or 10 years. Picking the X-by-wire or multimedia network will be significantly more difficult.
Two attributes of X-by-wire networks, speed and reliability, set them above the control networks. Higher speed is necessary to move more information and to minimize response time and latency. Frequently, redundant networks address reliability.
X-by-wire protocol definitions require a more robust, fault-tolerant design. This enables them to protect against problems like "babbling idiot" syndrome where a bad node can compromise a network segment.
One protocol targeted at X-by-wire applications is TTP/C. Developed in Austria, it's based on BMW's Byteflight. TTP/C is a time-division multiple-access (TDMA) network. It has a longer frame length than CAN, supporting data blocks of up to 240 bytes.
Flexray is a direct competitor to TTP/C. Originally developed by Philips Electronics, it's now managed by the Flexray Group, which is made up of companies such as DaimlerChrysler, Mercedes Benz, and Philips Semiconductors. The initial version of Flexray operates at 5 Mbits/s, but higher-speed versions are on the drawing board.
X-By-Wire Still A Ways Off As the technology is about five years away, the X-by-wire race is just beginning. Silicon is expected in 2002, but then it must be qualified. Furthermore, additional protocols may be proposed and significant changes to existing protocols might occur before X-by-wire is actually used in real products. On the other hand, high-speed multimedia networks probably will be standardized within five years.A number of multimedia networks are cropping up to address automotive infotainment environments. Unlike the control and X-by-wire networks, multimedia network specifications will probably be driven by peripheral vendors of radios and DVD players instead of the automobile industry.
This type of network needs the speed of the X-by-wire protocols but not the redundancy and reliability. After all, having an audio CD-ROM fail to play isn't as serious as having a nonworking brake system.
The popular four-wire, IEEE-1394 multimedia network is already used on high-end video equipment like DV camcorders. Unfortunately, the standard doesn't take into account the relatively hostile automobile environment. This has led to IDB-1394, a modified version of the IEEE-1394 standard. As with most multimedia network definitions, the IDB-1394 definition is an ongoing project.
IDB-1394 is under development by the Joint Automotive Working Group (AuWG). This group is a partnership between the IDB Forum and the 1394 Trade Association.
The Media Oriented System Transport (MOST) network originated at Oasis SiliconSystems AG. It runs on fiber-optic cable at speeds of up to 400 Mbits/s. This puts it on par with IDB-1394.
Smartwire is a ring network from Communication and Control Electronics Ltd. The architecture has limited fault tolerance via a loopback when a connection between nodes fails.
The 11-Mbit/s implementation of Smartwire is called Conan. A version called SuperConan runs at 22 Mbits/s. Both use the Digital Data Bus (D2B) automotive multimedia networking protocol standard.
The Automotive Multimedia Interface Collaboration (AMI-C) is a multimedia automotive consortium supporting IDB-C ITS (Intelligent Transportation Systems Data Bus). For more details on this CAN network, check out the IDB Forum Web site at www.idborum.org/.
Automotive multimedia networks won't operate in complete isolation from control and X-by-wire networks. One or more network gateways will tie these disparate networks together.
The emergence of CAN and LIN as popular control networks brought about a number of gateway implementations that link multiple CAN and LIN networks together. Links to X-by-wire and multimedia network segments will be needed too, but the lack of a standard for multimedia gateways will require custom configurations.
Sensoria Corp. and Delphi Automotive are two companies currently supplying router hardware and software support for multiple CAN and LIN segments. The routers additionally act as firewalls between segments, so hopefully the latest CD-ROM audio track won't wind up as a steering-by-wire node.
Another important aspect of automobile command and control systems is the type of operating system used. One type, OSEK, was a joint project started in 1993 by BMW, Bosch, DaimlerChrysler, Opel, Siemens, VW, and IIIT. Another operating system, VDX, was developed by Renault and PSA. Then in 1994, the two were merged into an open-ended architecture known as OSEK/VDX. It has significantly grown and now includes most major auto and automotive suppliers.
OSEK/VDX is an interface, protocol, and methodology that allows real-time embedded applications to be developed on any OSEK/VDK-compatible operating system. The underlying operating system isn't specified, and OSEK/VDX is supported by a number of different embedded operating-system vendors. This high-level definition should allow easy porting of an application from one processor to another.
The OSEK/VDX architecture consists of three components: communication, network management, and the operating system (Fig. 2). This approach makes it more extensive than an individual POSIX standard while it remains a well defined, all encompassing environment. By including communication and network management into the specification, OSEK/VDX addresses the major components for supporting most embedded, networked automotive applications. OSEK/VDX is designed to support environments that will be implemented using different network protocols like CAN.
The communication specification addresses the data-link layer and the network layer of an OSI network stack model. The communication API deals directly with the network and data-link driver layers. Synchronous and asynchronous message-based communication is supported. The definition is extremely flexible, and it has features like static and dynamic addressing schemes and periodic message transmission support.
The OSEK/VDX network management provides standard APIs for internetworking support, including support for network-related diagnostics. It's designed to tolerate temporary network failures. OSEK/VDX can handle network monitoring, although this feature may be augmented with hardware-specific network support.
The OSEK/VDX operating-system API addresses the typical resource and multitasking needed by a real-time, embedded application. This support includes task and interrupt support, resource management, and event and alarm control. Furthermore, OSEK/VDX supports non-, full, or mixed preemptive scheduling.
OSEK/VDX's preemptive scheduling support uses the typical priority-based ap-proach. Therefore, it can be easily implemented atop most real-time operating systems. The specification doesn't address the more complex strategies available in some real-time operating systems. Two examples are reservations and priority inheritance. Still, such features can be utilized by an application if the designer chooses to go beyond the standard OSEK/VDX specification.
In addition, OSEK/VDX includes an OSEK Implementation Language (OIL) specification for defining a particular processor and how specific applications will run on it. It has semantics for defining messages and tasks. OIL specifications are run through a System Generator to create C code that's combined with application and operating-system C code to generate an executable file. This file will run on an embedded processor.
OSEK/VDX allows the automotive industry to adopt a specification without committing to any operating system or processor. It's expected that OSEK/VDX will be widely used over the next few years.
Assembler, C, and C++ are the programming languages of choice for embedded automotive applications. The one potential exception is multimedia and consumer communication applications for devices that will interact with or be added by the consumer, such as cellular telephones and audio and video equipment. These platforms might use other languages, like Java, for application development.
Improving the reliability and long-term support of assembler applications is best addressed by minimizing the amount and size of these applications. Appropriate targets for Assembler include small network nodes found in LIN, device drivers, and interrupt support.
The C and C++ languages lack the sophistication of languages like ADA and Eiffel when it comes to specification, documentation, and requirement definition constructs. Rather than extend C and C++, therefore, a number of specifications narrow the scope of these two languages. The smaller language specifications are designed to eliminate constructs prone to errors, which add complexity and can cause support problems, plus the constructs that are typically unnecessary for real-time, embedded applications.
Two specifications that address the automotive space are MISRA C and Embedded C++. MISRA C is specific to the automotive arena, while Embedded C++ is applicable to all embedded applications. MISRA C consists of 127 rules. The subsets tend to be implemented as options to a compiler and linker such as the Safer C support included in Tasking's latest C166 development suite. Safer C is an implementation of the MISRA C rules.
Individual aspects of the rules can be enabled or disabled, allowing incremental migration of existing code to more easily occur. Project managers usually mandate the use of all rules by the end of this type of project, whereas a new application will always have the rules invoked.
The rules used to specify these subsets usually follow good programming practice. For example, MISRA C rule 3 indicates that assembler and C shouldn't be mixed. Another specifies that #define shouldn't be used for typedef overloading. Additionally, pointer usage is typically a limited area.
Automotive programming, operating-system, and network standards will definitely improve the flexibility and compatibility of automotive command and control systems. The programming and operating-system standards are equally applicable to automotive and nonautomotive applications. They also address a range of development requirements.
The networking standards, on the other hand, still lack the depth necessary for interchangeability at the component level. This is expected to continue as automotive vendors keep pushing proprietary enhancements and components. Eventually, networked electronic components may be as reliably interchangeable as nuts and bolts. But, it might take 10 years to get there.
For a list of relevant manufacturers and organizations, see page 4.
| Companies And Organizations Mentioned In This Report | |
|
Automotive Multimedia Interface Collaboration www.ami-c.org BMW www.bmw.com Communication and Control Electronics Ltd. 01483 540222 www.candc.co.uk DaimlerChrysler (248) 576-5741 www.daimlerchrysler.com Delphi Automotive (248) 813-2000 www.delphiauto.com Flexray Group www.flexray-group.org General Motors (800) 555-1212 www.generalmotors.com IDB Forum www.idbforum.org OSEK/VDX www.osek.org Mercedes Benz (800) 555-1212 www.mercedes- benz.com Microchip (800) 555-1212 www.microchip.com |
MOST Cooperation +49 (0)721-9 66 50 00 www.mostcooperation.com Motorola Semiconductor (512) 502-2100 www.mot-sps.com Motor Industry Software Reliability Association www.misra.org.uk NEC (800) 268-3997 www.nec.com Oasis SiliconSystems AG (512) 306-8450 www.oasis.com Philips Semiconductors (800) 234-7381 www.semiconductors. philips.com SAE International (724) 776-4841 www.sae.org Sensoria Corp. (858) 673-4460 www.sensoria.com Tasking (781) 320-9400 www.tasking.com TTP Forum www.ttpforum.org |