Observers of the automotive and electronics industries have taken note of the interesting parallels in the history of those markets. Both originated and gained momentum in the latter half of a century, changed fundamentally and began to mature in the beginning half of a new century.
In their early stages, both saw expensive and low-cost implementations and reliable and unreliable products, as well as easy-to-use and hard-to-understand vehicles. It was only 30 or more years after the first systems were used that the focus shifted from bigger, flashier, more feature-rich implementations to lower-cost, more reliable, easier-to-maintain ones.
Currently the parallels continue. In the computing environment, the challenges are higher-integration, higher-performance electronics and increasingly network-connected 8- , 16- and 32-bit processors for both embedded control and user-interfaced personal computing.
Gary Miller, member of the technical staff in Motorola's Advanced Vehicle Systems Division, advises designers not to be blinded by the power of new-generation RISC powertrain MCUs. With less support in the development cycle, there can be critical delays.
In the automobile environment, engineers are considering a transition from 8- and 16-bit devices to more sophisticated 32-bit processors. Electromechanical control systems with independent 8- and 16-bit microcontroller intelligence may shift to drive-by-wire environments with individual subsystems that are controlled by 32-bit processors but that communicate with other 32-bit subsystem controllers via high-bandwidth buses and network connections.
In the wider computing arena, where operating system (OS) vendors are fighting to dominate the new connected computing environment, they are searching out what features a net-centric OS will need and what is necessary to provide proper management and control in a distributed context.
In the automobile industry, too, common standards for connectivity such as Control Area Network (CAN) and the local interconnect network (LIN) are merging into the mainstream, and OS and network-management standards like OSEK are being adopted.
Driving all of this activity in the automobile is, as in the wider computing context, a market that is rapidly expanding and demanding more sophisticated systems, but also lower cost and faster time-to-market. Contributions to this week's section focus on the forces that are changing automotive subsystem design and control.
Unlike the embedded and enterprise environments, where the sheer number of new users of computing devices is creating an expanding market for both hardware and software, growth in auto electronics sales is approaching 10 percent a year in spite of the fact that auto production is only slowly inching upward.
According to George Fry, author of Automotive Chips-2000, published by Forward Concepts of Tempe, Ariz., vehicle production worldwide is estimated to expand at under one percent per year from 1996 through 2005. Integrated circuits and other semiconductor devices used in those same autos is growing at over eight percent a year.
Fry estimates the global demand for vehicle electronics systems, which constitute on average 20 percent of the cost of a new car, to climb from $53.5 billion this year to about $75 billion in 2005. Fueled by demands for reduced emissions, improved fuel economy and safer and more user-friendly vehicles, this growth is driven by several factors:
- The first driver is the growing semiconductor content in automobiles.
- Next is the migration of sophisticated electronics systems from high-end, smaller-volume luxury autos to more mainstream, high-volume vehicles/
- Last is the telematicization of the passenger compartment.
Telematics, said Fry, is a term coined by Motorola and is now used widely in the auto industry to describe consumer products and supporting systems that deliver information, communications and entertainment to travelers through handheld or in-vehicle devices.
This situation raises a number of dilemmas for auto manufacturers. How do they satisfy the demands of the consumer plus those of the government for lower emissions and increased safety and keep overall costs down? This dilemma has led auto manufactures to shift away from their traditional strategy using only the most well-tested and mature of electronics technologies in their systems after a design-to-market cycle that was years long.
The flat demand for autos means that a company can only increase profitability by either increasing sales or adding features that make consumers want to pay more. According to Ron Stence, systems engineer in the Advance Vehicles Systems Division at Motorola Inc. (Austin, Texas), they are turning to leading-edge technologies like advanced microprocessors and distributed networking. It is the only way to satisfy the increasing demands of governmental regulations.
This dependence on leading-edge technologies that are unproven as far as providing increased performance and lower emissions means that the automobile industry has had to develop new strategies. Rather than develop proprietary networking schemes, proprietary operating systems and highly customized integrated circuits in-house, there is a move to standardize tools, network protocols, network-management methods and operating systems.
Stence pointed out that such standardization solves, or at least significantly ameliorates, many problems. For example, the automobile companies and the suppliers of electronics to that market have been important in the development of the IEEE Nexus 5001 debug interface standard. The standard is a common specification for building additional capabilities into processors that would allow development tool vendors to create debuggers and other tools that are not locked into a single processor architecture.
"Currently almost every major processor vendor has incorporated new on-chip debug capabilities," Stence said. "What they share in common is the ability to get greater visibility into the internal workings of specific architectures."
But, he said, that is all they share, since in order to make use of such advanced features, tool vendors have to develop products specific to each architecture and developers have to buy multiple tool chains. "The more tool suites that have to be purchased and learned, the higher the cost of development, the more time it takes to learn the various tools and the higher the price of the end system and the longer it takes to get to the market," Stence said.
"And rather than push for a tool suite or a set of specs that were specific to the requirements of the automotive industry, the effort has been made," said Stence, to make the standard as widely applicable across multiple applications and industries as possible.
In his contribution to this section, Gary Miller, a member of the technical staff in Motorola's Advanced Vehicle Systems Division, points out that with a new generation of RISC powertrain MCUs in the development cycle, it will be more difficult to debug the ECU reliably and efficiently.
"There is less support for the development process in the new high-performance single-chip RISC MCUs, which could create critical and costly delays in the development cycle," writes Miller, who co-authored the article with Kevin Hall, R&D project manager, Agilent Technologies (Colorado Springs, Colo.).
"And as powertrain MCUs continue to evolve, superscalar or multiple-issue RISC implementations may be used as the central processor. With the capability to issue multiple instructions in one clock cycle, this will only magnify the development-support problem. Needed is a strategy that both automotive and tools developers can agree on," said Miller.
While the fly-by-wire approach to linking microcontrollers and processors in the auto engine, powertrain and transmission is becoming ubiquitous, automakers have faced problems. First, using networked microcontrollers allowed elimination of some rather expensive electromechanical subsystems. More electronics has meant more wiring, increasing the cost of installing the wiring harnesses in autos-one of the most labor-intensive and least-automated steps in auto manufacturing. More wires also means more weight and a more complex system, reducing reliability at a time when the industry is under pressure to increase it.
The first step in reducing this cost has been a shift from a one-wire/one-network protocol approach to multiplexed approaches, combining power and data or various data buses into a single set of wires. Until recently, said Joseph J. Lemieux, senior applied specialist at Electronic Data Systems Inc. (Detroit, Mich.), automakers had not only different mini-networks for each control subsystem, but each manufacturer also had different protocols for each subsystem. Rather than reducing cost, it only shifted them, Lemieux said, requiring semiconductor components specific to each subsystem and even each manufacturer.
'In name only'
Standards for multiplexed buses are slowly making their way through the auto industry to solve that problem. In the United States automakers are committed to the Society of Automotive Engineers' (SAE) J1850 bus specification. Lemieux said,"The problem with J1850 is that it is a standard in name only, since all of the U.S. automakers have implemented versions specific to their vehicles," driving up its cost far beyond original forecasts.
Gaining ground on J1850, due in part to the merger of U.S. and European automakers and the fact that many semiconductor suppliers have championed it, is the CAN. Because the CAN bus is used by European automakers and suppliers and because it is widely accepted in the industrial control environment, it is much lower in cost-about 50 cents per node versus about $5 to $10 per node. Beyond that, there are many technical advantages that will make it attractive to auto designers, Lemieux said. While it is based on Ethernet's Carrier Sense Multiple Access Scheme, which is not particularly real-time or deterministic-a necessity in the auto environment-CAN has added features that will satisfy those requirements.
However, as fast as technology has allowed automakers to reduce the number of wires and buses in the auto, the requirements of safety, reliability and the entertainment needs of passengers is pushing them toward other bus specifications. At one end of the performance spectrum is a new specification, the LIN, the details of which are explained in an article by Dan Butler, principal applications engineer, and Rodger L. Richey, applications project manager, at Microchip Technology Corp. (Chandler, Ariz).
"Many portions of the auto environment that operate on human time, such as the doors, wipers, steering wheel, do not need real- time and deterministic," said Lemieux. "Technically it is just a low-speed, shorter-distance subset of CAN. What it will come down to is if the price per node can match that of the full CAN implementation."
At the other end of the spectrum, several solutions have been proposed to handle the increasingly high bandwidth and multimedia nature of networking in the passenger area of the car. One partial solution is the AutoPC, proposed by Microsoft Corp. (Redmond, Wash.). The reliability aspects of this Windows CE-based alternative is discussed by contributor Bruce Johnson, development manager in Microsoft's Automotive Business Unit.
Aiming at a more robust solution are companies such as Embedded Planet, Motorola and QNX, which have proposed the MobileGT spec, targeted narrowly at automotive driver information systems. More ambitious and most likely to dominate is the SAE-proposed 250 kilobit/second Intelligent Transportation System Data Bus (IDB), and its higher-bandwidth, multimedia-oriented extension, IDB-Multimedia (IDM).
Automobiles, more than the desktops and the new net-centric applications, will need a common software environment within which applications code can be written that is transparent to the hardware and network system. Many companies would like their OS to fill this role, but that function will probably be filled by OSEK/VDX, which came out of the European automobile market. Initially developed as a network-management protocol, OSEK/VDX has evolved into a common applications programming interface used by RTOS vendors, including Wind River and Accelerated Technology, to develop OSEK-compliant versions of their proprietary OSes.
Despite companies' enthusiasm to jump on the OSEK/VDX bandwagon, the specification is not without problems, said Ken Tindell, chief technical officer at Northern Real Time Applications Ltd. (York, England), and author of an article on the real-time nature of auto electronics. "Aside from defects that can lead to uncommanded actuation, there are defects that lead a compliant OS to need more RAM, ROM or CPU for little or no functional gain," Tindell said.
"This is a serious problem for users of OSEK. Much is left for the vendor to define, and this puts a great responsibility on the vendor to discover and resolve the definition problems," he said. "Also, many vendors are claiming OSEK compliance for products that do not actually meet the demands of the specification. This is undermining the aim of OSEK for portable application code."
Despite such concerns, Tindell thinks that solutions will be found. "After all, OSEK/VDX and, for that matter, CAN are still relatively young and immature standards," he said. "There are bound to be problems that need to be resolved. And they will be."
Meanwhile, several contributions detail the impact of 32-bit microcontrollers. "In applications such as powertrain control systems, 32-bit RISC architectures are expected to gain up to 25 percent market share within five years," writes Infineon Technologies Inc.'s (San Jose) Patrick Leteinturier, director, system definition, and George Huba, manager, technical marketing and support. With safety systems and smart cars, the adoption rate may be even faster. "Automotive control systems are developing to such an extent that they are approaching the scale of the most complex avionics systems," they said.