Power-train computers adjust the engine and transmission for best performance, and safety processors remind you to use seat belts, warn you of hazards, and deploy air bags during an accident. Embedded controllers also drive motors to operate power seats, windows, and mirrors. Driver-information processors display or announce navigation and traffic information along with vehicle diagnostics. Embedded controllers are even keeping track of your driving habits". In addition, enormous activity occurs in the entertainment and mobile-computing areas. These features add up to plenty of opportunities in automotive electronics for embedded designers, software engineers, and development-tool suppliers.
To take advantage of these electronics opportunities, designers must concentrate on the automotive industry's primary design goals of safety, cost, and reliability. Safety is paramount in automotive-embedded-system design. An unexpected actuation of any system while an automobile is traveling at 70 mph could be disastrous. As you have seen in recent news, an air bag that is too powerful or that deploys at the wrong time may also be life-threatening. Manufacturers insure against safety problems by doing extensive hardware and software testing.
In addition to underscoring product safety, designers must fight to reduce the recurring cost of automotive-electronics systems. Manufacturers may use the same engine-controller design, for example, in many automobiles over several model years. North American automotive manufacturers alone ship approximately 15 million vehicles every year. Furthermore, today's manufacturers are forming global partnerships, so an embedded system could be on a production line anywhere in the world. Reducing the parts cost by just a few cents could add up to millions of dollars in savings over the life of the system.
Reliability may be the toughest design goal to achieve because of the rugged environment of the automobile. Your circuitry must survive nearby high-voltage EMI, temperature extremes from the weather and the heat of the engine, and severe shock from bad roads and occasional collisions. Your high-reliability design tools include extended-temperature-range parts, derated components, redundant circuitry, worst-case simulations, and careful mechanical design. Although testing time grows with the complexity of the system, a reliable controller also requires complete software testing to verify every state and path. A single bug that slips through testing may force a very expensive recall to update the software.
Count the bits
A successful automotive-electronic design depends on careful processor selection. Modern power-train controllers for the engine and transmission generally require 32-bit CPUs to process the real-time algorithms. Other areas of the automobile, such as safety, chassis, and body systems, use both 16- and 32-bit processors, depending on control complexity. For example, a 16-bit processor is sufficient for a single-air-bag system. However, for multiple air bags and occupant sensing, the peak computing load dictates a 32-bit processor. Newer air-bag-control systems may have to sense multiple collisions from the front and side, then sequentially release front, side, and possibly headrest air bags to protect occupants. Although an air-bag controller simply scans sensors for most of its life, the processing power must be available to complete the entire decision algorithm and actuation routines in just a few milliseconds.
Historically, low-cost 8- and 16-bit processors were the norm in automotive controllers, and software engineers developed most of the code in assembly language. However, today's shorter development schedules and increased software complexity have forced designers to resort to a higher level language in which designers can easily reuse modules from project to project. Although some critical timing situations still use assembly language, the software trend in automotive embedded systems is toward C.
In addition to analyzing the language, controller designers must analyze the need for an operating system. Although there is substantial deterministic activity in automotive embedded controllers, few real-time operating systems (RTOSs) exist. With just a small number of asynchronous inputs, most automotive controllers meet the real-time requirements by sequentially polling sensors. Power-train controllers sample inputs according to engine speed; safety, chassis, and body controllers check sensors based on time.
However, as the complexity of embedded systems increases, the automotive industry will adopt RTOSs and more sophisticated software-development tools. Highly integrated entertainment, speech-recognition, and navigation systems already employ real-time software to deal with asynchronous inputs from the user and communications sources. For example, an RTOS from QNX Software coordinates real-time Global Positioning System (GPS) information with map displays and audio commands for an in-car navigation system. What's more, IBM visionaries predict pervasive computing and plan to include a mobile client-server architecture and embedded Java in the company's next generation of automotive software.
Nonetheless, automotive embedded-system designers complain that commercial RTOSs are just too large and feature-rich for high-volume, memory- stingy vehicle controllers. To address these complaints, European automotive manufacturers have defined the OSEK standard as a common platform and application-programming interface for automotive-embedded-controller development. (OSEK derives its name from the German phrase for "open systems and interfaces for in-car electronics.") OSEK specifies a communications protocol, network-management rules, and a memory-efficient operating system for automotive controllers. Although industry experts have questioned the readiness of the OSEK standard, Wind River Systems, Accelerated Technology, and Integrated Systems have announced compatible operating systems.
Car networks
Designers face not only the challenge of dealing with extra RTOS software but also the challenge of squeezing in the hardware and code for in-car networking. Networks are a recent addition to embedded controllers. The first automotive network was simply a UART connection between two processors. This serial connection allowed two controllers to easily share information, but there was no simple way to add more nodes to the network. Then, to satisfy new government emissions regulations, vehicle manufacturers and the Society of Automotive Engineers (SAE) developed J1850, a specialized automotive-network protocol. J1850 met the requirements of the California Air Resources Board and the Environmental Protection Agency (EPA) for a standard interface into the engine and transmission controller to retrieve emissions data. J1850 soon became the in-car-networking standard and replaced the UART serial communications. Manufacturers also found that they could use networks to reduce harness wiring and its associated weight and manufacturing costs.
In a global economy, a single network standard would solve several problems. Current EPA regulations require that test and diagnostic tools interface to J1850 even though embedded-systems designers might prefer CAN because of its higher data rate. Some North American engine and transmission systems use CAN to communicate, but these systems use a gateway processor to adapt to J1850. The SAE is investigating the possibility of changing the EPA test tools to CAN. However, the SAE's biggest obstacle is the large number of facilities that uses J1850. Every dealership would have to retrofit its test and diagnostic tools at significant costs. A single network standard would also lower development and production costs, because US automobile makers have agreements with manufacturers worldwide to exchange engine and power-train components, including controllers.
Algorithm development
Controller-software development begins with a dynamic system-simulation tool, such as Simulink from The MathWorks or MATRIXx from Integrated Systems. By integrating an engine model with proposed sensors, actuators, and a controller algorithm, the designer can adjust fuel, air, and exhaust gas to optimize performance under varying loads. The simulation produces and documents an algorithm for one feature of the control system. For example, engine controllers include an algorithm to recirculate exhaust gas under certain engine load conditions and to minimize uncombusted fuel emissions. The designer can adjust the algorithm for the best engine horsepower and meet EPA emissions requirements.
When the simulation is complete and engineering approves it for production, the specification for the algorithm goes to the software-development group for implementation. Software engineers use off-the-shelf compilers, debuggers, and simulators from tool suppliers such as Wind River Systems and Software Development Systems to code and test the algorithm. A systems engineer then combines individual engine-control algorithms, communications software, and diagnostic software with prototype hardware for integration testing. Manufacturers use a number of intermediate test stands to verify controller operation before installation in a test vehicle. Test stands can be anything from a simple electromechanical tester with a switch for adding or removing a load from the controller harness to a dedicated piece of hardware that simulates an engine in real time.
Finally, engineers install the controller and software into an actual automobile to test the control system as well as the physical engine and transmission. Based on measured performance, engineers can adjust control-system coefficients to maximize performance and to account for inaccuracies in the original engine model. Nonvolatile memory stores control-system coefficients to facilitate field changes . For example, Cadillac rcently delivered cars that had emissions tests with the air conditioning off. The EPA later retested the vehicles with the air conditioning on and found significant emissions outside of the acceptable range. Cadillac corrected the problem by updating engine-controller coefficients in the field.
The automotive world presents some interesting challenges to the embedded-systems designer. As silicon increases its presence in the automobile's mechanical world, the embedded-systems designer must analyze and select from the flood of new technology to stay near the leading edge and to maintain the traditional automotive goals of reliability, cost, and safety.
0 Comments:
Post a Comment