Almost all the future technologies expected to appear at some point in cars involve huge amounts of embedded software. For manufacturers and Tier I suppliers, the increase in embedded software will require a change in software development methodology in order to control the growth of their software teams and to deliver software that meets reliability requirements. A little background on automotive electronics will underscore why this growth in embedded software needs to be anticipated and tackled now.

Electronics inside an automobile are delivered in the form of modules known as electronic control units (ECUs). These are actually boards containing chips in some sort of housing that protects the delicate electronics in the hostile environment of a car. A modern high-end car can have as many as 80 or 90 ECUs. The most complex ones operate the powertrain.

Simpler ECUs operate superficially simple functions such as the seat and mirror adjustments, but even these seemingly trivial functions must be networked together so that the seat and mirrors can be adjusted for different drivers. The wiring to connect these ECUs is itself a problem, leading to wiring harnesses that can weigh over 50Kg, and, worse, have a large number of connectors, each of which will increase warranty costs when it occasionally fails.

On the horizon are two big transitions that will account for most of the projected increase in the electronic content of cars. One is the growth of telematics and in-car entertainment, combining wireless technology, GPS (global positioning system), digital radio, internet access and so forth. The other is the transition from mechanical (and hydraulic) activation to electrical activation.

Electronics technology will lead to electrical valve operation replacing the camshaft, to steer-by-wire, brake-by-wire and drive-by-wire (collectively known as "X-by-wire"). On top of these technologies will come further developments such as automatic lane-following and intelligent cruise control that takes account of the distance to the car ahead. Both hybrid (internal combustion and battery) and fuel cell electric drive will also include a large software component, as will other technologies that don't fit in any particular category, such as drowsy driver detection.

The combination of growth in software content, with the continued need for reliability from a finite supply of software engineers, is creating an optimization problem that must be tackled before it gets worse. Automotive companies who see this as a software problem, rather than a hardware problem, are building mathematical models of subsystems even before they worry about implementation. But such models still require the creation of large amounts of software and an efficient network of ECUs to execute the code and interface to the mechanical systems of the vehicle.

What we need is a change in methodology. To reduce wiring weight, ECUs should be located close to whatever they control. Mount the engine control ECU on the engine; move brake controls close to the wheels; and so on. To reduce connector count and thus warranty costs, reduce the number of ECUs. To keep reliability up, add redundancy for the most critical functions. The network connecting the ECUs needs to guarantee service for functions like X-by-wire. Optimization of this sort can be achieved only by taking a more systemic approach to the architecture of the electronics, which, in turn, requires quantitative analysis, both of potential architectures of ECU networks and of the internals of the ECUs themselves.

Optimization is not all we need. Creating and testing embedded software creates a productivity problem that must also be solved. The automotive market is less concerned with immediate time-to-market than other industries, since it operates on a long time horizon. However, it is very concerned with reliability and software productivity, without which there will be uncontrollable growth in the number of engineers required. Some areas of a car, such as braking, also have obvious safety-critical reliability requirements. In less critical areas, increased reliability shows up as decreased warranty costs.

The old approach — bench testing software using hardware — is running out of steam. For one thing, it is becoming too difficult to build the hardware boards needed for the highest performance subsystems such as power train. For another, the software engineers have too little visibility into the internals of the ECUs.

A comprehensive solution exists to solve the architectural analysis crunch while actually increasing software reliability — the virtual platform approach. A virtual platform is a very fast simulation model of an ECU or network of ECUs. It is fast enough to allow the full software load to be run and is accurate enough to produce the true timing and the true network traffic that the real ECU subsystem will experience.

For the software engineer, a virtual platform also provides much better visibility than the older bench-based approach, leading more quickly to software that is more reliable, and to an optimal architecture for ECUs and their associated wiring and connectors. All without requiring explosive growth in the number of software engineers.

Until recently, simulation technology has not been able to deliver a practical virtual platform. Simulation models of processor-based ECUs were too slow to run a real software load including real-time operating systems, device drivers, complex timers and so on. Often models were not accurate enough either, so that the measurements made were only a rough guide to actual performance, which is next to useless in a complex real-time environment like a car.

But recent developments in simulation technology, which enable simulation models to run in real time with real accuracy, finally have made virtual platforms practical. Forward-thinking automotive companies are now taking this route; the others will surely follow.

Paul McLellan is vice president of marketing and business development at Vast Systems Technology Inc.