The electronic content of the automobile is expanding dramatically,driven by several concurrent forces, including consumer demand forentertainment systems and convenience functions, the addition ofenhanced safety features, and government emission control regulations.
Consequently, engineers are working to raise the functionality ofelectronics, while simultaneously devising strategies to improve faulttolerance and provide fail-safe operation of all critical systems.
On average, a new passenger vehicle today features about 80integrated and networked systems. And while the control of such systemsas powertrain, ABS(Anti-lock BrakingSystem) , airbag control and body electronics functionshas traditionally been self-contained, a great deal of value can beadded by exchanging data between systems.
For example, traction control systems optimize the grip of tires onthe road surface, which requires that the brakes be modulated and thepowertrain systemretard engine torque at the same time. This can beaccomplished relatively easily through a simple serial communicationslink between the ABS ECU(electronic control unit) and the powertrainECU.
However, as the number of interconnects and gateways betweendifferent systems expands, the growing number of interfaces and likelybottlenecks increases the potential that the overall vehicleelectronics network may grow too complex.
Overloaded networks are not efficient. They require increasedtesting and validation, the complexity increases the possibility ofsystem faults, and total system cost is not optimal. A solution to thisgrowing complexity is evolution of the vehicle electronics into adomain architecture connected by a backbone (Figure 1 below ).
|Figure1. Expected evolution of vehicle electronics architecture|
In this type of in-vehicle network, mechatronic solutions (which combine mechanics, electronics andcomputing ) will be deployed, and sensors will become active andsmarter, with digital interfaces. Power components will integrate morecontrol and diagnosis, and microcontrollers will support more robustsoftware, as well as offer fail-safe, fail-silent and fail-functionalcapabilities.
The move from today's decentralized architecture to centralizationwith global and coherent control will result in what can be thought ofas a three-part vehicle operating arrangement, where a “real” driver issupported by a “guardian angel” that provides risk management and a”virtual co-driver” for driver assistance.
Guardians and codrivers
The “guardian” will consist of both passive systems, such as passengerdetection, tire pressure monitoring and collision warning, and activesystems, such as collision avoidance. The “co-driver” will performfunctions that make the driving experience easier and more pleasant,such as passive blind spot monitoring and vision enhancement, andactive navigation, lane departure and parking assistance.
Safety, of course, is a major concern in automotive systems. Whenapplied to a whole system, the key is dependability — dependablesensing, dependable actuation, dependable computation, dependablecommunication and interconnection, and dependable power. Within thesafety path, there can be no common-cause failure mechanisms.
This means moving the system guardian outside a firewall (Figure 2 below ), where it servicesall the system elements individually. It also means a need for safetythrough redundancy. Safety is today the object of a substantial amountof work in the automotive market, very often using the generic IEC61508 safety standard, and isbecoming so important a consideration that an automotive-specificstandard, the ISO26262, is nowin development.
A key to developing such systems will be a move to software-enabledfunctionality, with dedicated hardware being replaced by softwarealgorithms running on a microcontroller (MCU). Signal processing andcommunication will move from analog to digital, and mechatronicsolutions for shifting, hybrid control, steering and braking will beenabled by drive-by-wire capabilities.
|Figure2 Safety path using external “guardian” circuit|
To support the enhanced capabilities of the software, the industrywill move to more-powerful MCU architectures that offer real-time andfail-safe capabilities, broad peripheral sets and eFlash to support thenecessary high performance and network connectivity capabilities.Multi-core MCUs are the solution that is emerging to meet all of theserequirements.Multi-Core MCUs
A multi-core MCU, which combines two or more processor “cores” on asingle die, offers increased performance over single-core devices. Forexample, in comparison to a traditional MCU, a dual-core MCU offers atleast double the performance at the same clock frequency. In fact,tests on a dual-core MCU have shown the same performance can beachieved at 200 MHz as a single-core MCU operating at 500 MHz.
An important ancillary benefit of the improved performance is thatthe power consumption and heat generation of a multi-core device arelower for the same level of performance as a single-core device. Inaddition, the faster clock of the single-core device requires fastermemory, which further increases the power consumption and requiresspecial packaging to dissipate the heat.
This power/performance comparison refers to a multi-core device, inwhich each processor core has the same architecture. Program and dataare shared, so the user can theoretically run any piece of software oneither core, although automotive electronics developers do notcurrently plan on plan dynamic software allocation.
In automotive applications, an important benefit of this multi-coreapproach is that it allows redundancy in critical applications. Forexample, safety monitors can readily be established, in which one coremonitors the other.
Multi-core systems can be classified according to their memoryarchitectures and their communication mechanisms. Spreading atraditional processing-intensive application equally across multiplecores of the same type is referred to as a “homogeneous” approach. Insuch a scheme, a system may be designed for redundancy, as in theexample above.
Alternatively, an application requiring high performance may beconfigured with identical code running on each core, processingdifferent parts of a data set. Such an architecture lends itself wellto use of “coarse-grain” software, which deals with large sections ofcode and is optimum when there are relatively few modules tounderstand.
Heterogeneous computing architectures are built around conventionaland specialized processors working cooperatively. The idea is to deploymultiple types of processing elements within a single workflow, witheach performing the tasks it does best. Software in this architectureis best structured as “fine-grain,” in which there are numerous smallcode modules. Fine-grain components tend to include functionalitiesthat can be reused in multiple applications.
|Figure3. Vision Instruction Processor principal blocks|
Infineon was one of the first suppliers of heterogeneous multi-coreMCUs for automotive applications, exemplified by the company's AUDO andAUDO NG devices, which pair a TriCore MCU with a separate PeripheralControl Processor (PCP). This architecture optimizes for the type ofdeterministic, real-time performance required in engine control andother powertrain applications.
Another example of a multi-core processor for automotiveapplications is a VIP (Vision Instruction Processor). Infineon hasdeveloped a prototype VIP (Figure 3,above ) that is a multi-processor device for camera-based systemsthat address the increasing demand for driver assistance to increasecomfort and safety.
The Infineon design contains four SIMD(single-instruction, multiple data) cores and an ARM9 processor. Each SIMD coreconsists of a general-purpose core and four PE (processing element)arrays. Performance of the VIP is 14,400 MIPS, or 9,600 MMACs.
Included are a 6-layer bus system (128 bits at 150 MHz), a parallelinterface (2 x 16 bits at 80 MHz) for independent data transfer to ashared memory, an ARM peripheral set with EBU, I2C and USB. Powerconsumption is 300 mW at 300 MHz for the SIMDs and 250 MHz for theARM9.
|Figure4. Flexibility can be provided by a design that offers both homogeneousand heterogeneous operation. Top – heterogeneous Mode and Bottom -homogeneous Mode.|
An emerging option for powertrain and other applications thatrequire deterministic real-time performance is an architecture capableof operating in either homogenous or heterogeneous mode, with bothidentical cores and a specialized processor (Figure 4, above ). This type ofarchitecture will allow the user to select which cores to use to meetthe needs of an application.Software Considerations
Of course, there are costs to the embedded developer using a multi-coreprocessor. For example, in many cases developers must thread theirapplications, and effectively threading an application is not a trivialtask.
There are also issues of load partitioning among multipleprocessors, and of ensuring that the software has a stable coarse-grainarchitecture. This requires care to ensure synchronization to preventprocessor stalls while awaiting the results of other threadedcalculations, and greater expertise in error detection and debugging.
Supporting multi-core MCUs will demand significant changes insoftware architecture, including more formal description andstandardization efforts. The way software is developed will change, andwill require development of algorithms, languages, compilers andexpertise in parallel computing that have not been previously necessaryfor automotive applications.
Robust software partitioning will see multiple applications ridingon an
As software complexity increases, modules will be “outsourced”across a manufacturer's supply chain, and there will be very littlesingle-source software. System developers will integrate software frommultiple suppliers onto one platform, and will require “clean” softwareand architectures for reuse by multiple suppliers.
Greater software complexity will also demand the ready availabilityof a complete menu of suppliers (OEMs and third parties), libraries andoperating systems. Chip suppliers such as Infineon will do the lowest,MCU instruction layer, and others will develop on top of thisfoundation.
Development tools for the multi-core environment need to bemodel-based, support emulation and calibration of high-speed multi-corearchitectures, provide total compatibility between the production andinstrumented devices, and allow fast prototyping.
Multi-core processor development tools for mapping an application ona simulator need to balance the load on the simulator, then on thedevice. They need to verify that code is loaded into the right area ofthe memory, verify memory consistency when information is shared, andboth verify optimization and minimize contention, which should ideallybe held to less than 5 percent.
A major requirement for software development is compilers thatsupport multi-core. The goal is to have as much application softwaredeveloped by autocoding as possible; Infineon estimates that 80 percentof application software for powertrain systems will be developed inthis manner by 2013.
Overall, the tools will allow the developer to try out differentways of partitioning an application to optimally distribute it acrossmultiple cores. For example, they would allow the designer to evaluateuse of one processor for control and one for data tasks, and comparethat with an architecture using one processor for both control and datatasks and an SIMD (Single Instruction, Multiple Data) core for signalprocessing, and other special-purpose processors for the remaining dataprocessing.
As noted, there is already a track record for multi-core processor usein automotive applications. The use of such devices will increase inautomotive applications because of the growing need for increasedperformance with lower power consumption.
The need to reduce the number of ECUs in vehicles, and theinterconnections between them, will lead to the emergence of new, morecentralized architectures that are more efficient and reliable, lesscomplex, and more cost-effective.
This migration will require changes in software architectures andmapping (e.g., OS, libraries, drivers), and will need new tools tosupport the development, reuse of legacy code, validation andqualification. The long-term result, however, will be expanded vehicleperformance with vastly improved safety and unmatched comfort.
Patrick Leteinturier is SeniorPrincipal, Automotive Systems, at InfineonTechnologies North America