The challenges of electronics.

Electronic systems on the car have advanced at a rapid rate in a very short space of time. It was only in 1967 that the first vehicle took to the road with any kind of controlling program--this was the electronically controlled fuel pump that did not even use software. In the current Mercedes-Benz 5-Class there are, depending on the options, more than 50 controllers controlling different functions while 600 signals pass along the cables and around 150 electronic messages are multiplexed onto three buses. It was necessary to write 600,000 lines of program code to make the car "smart". By 2015, it has been estimated that there will be around 100 million lines of code on a high-end car. Today, electronic systems and controls account for around 20% of the value of the average light vehicle. However, while 90% of the innovations in today's vehicles are based on developments in electronics, according to Siemens VDO, they account for about 70% of the quality problems, according to DaimlerChrysler.

The growth in the number of microprocessors on a vehicle has been so rapid that the engineering consultancy Ricardo reports it is both economically and practically unsustainable. Economically because each microprocessor requires its own separate power supply and EMC/RFi protection, and practically as the process of functional integration of so many nodes becomes unmanageable

[ILLUSTRATION OMITTED]

Rapid changes in silicon design and manufacturing technology, combined with economies of scale for higher performance microprocessors, is bringing technology, which is currently limited to the desktop environment, says Ricardo, into the realms of automotive applications. The outcome of this trend is that microprocessors, with a performance that is at least 10 times faster than today's automotive processors, will be used in vehicle applications before the end of the decade. This will lead to dramatic changes in vehicle electronic architectures, functionality, safety strategies and development tools. While this also means that the carmakers will move from being systems integrators to software integrators, the process is still in the transitional stage.

It is software, though, that is playing an increasingly decisive role in the realization of electronic innovations. For the customer, this might make itself felt in the form of new functionality or in the maintenance of a vehicle's value over its lifecycle. Possibilities are, for example, software updates/upgrades for motor controls, suspension or telematics. From the carmakers' point of view, software is therefore becoming an additional core competence. It is, however, "one of the problems downwind" according to David Oates, managing director of AB Automotive Electronics. Software complexity is rising to a considerable degree--investigations show that the volume of software doubles every 18 months. This is mirrored in the rising proportion of development costs that are devoted to software. Currently, depending on the model and level of equipment, 50-70% of the electronics development cost is being spent on software. The downside to this is that the risk of software errors grows exponentially--and it is this which is manifesting itself in the front line when cars break down for electrical/electronic reasons. "Not everything talks with everything else on a car," says Remi Kaiser, general director for Delphi France. "The main issue is to ensure that everyone is working as a team and that the correct communications can be established. This means having the same good set of tools. However, one of the issues is that of coding where each change of layer increases the chances of mistakes despite the comprehensive testing that is done."

During the execution of a system safety program, developers of embedded control systems recognize the need to protect against potential software failures. Unlike mechanical or electrical/electronic hardware, software does not wear out over time, and it can be argued that software does not fail. However, software is stored and executed by electronic hardware, and the intended system functionality that is specified by the software may not be provided by an embedded system if potential electronic hardware failures occur or if the software is incorrect.

According to a recent paper on automotive embedded control systems, presented by Delphi, typical sources of potential hardware failures, which can be either internal or external to the controller the software executes on, include memory failures in either the code space or variable space, CPU failures, and peripheral failures. For example, memory cell failures can cause conditions where the software inadvertently jumps to the end of a routine or into the middle of another routine. Interrupt failure modes, such as return of incorrect priority or failure to return--thereby blocking lower priority interrupts--can also be caused by memory corruption. Software logic errors may arise due to incomplete or inconsistent requirements, errors in software design, or errors in code implementation. Software logic errors can lead to failure conditions such as infinite loops, incorrect calculations, abrupt returns and taking a longer time to complete routine execution. Additionally, software stored in an embedded system may not be correct if the tools necessary to configure, compile and download the software do not function as expected.

"The overall aim is to make electronics systems that are as reliable as mechanical ones that they replace or supplement," says Dr. David Ward, head of research in the electrical group at MIRA in the UK. "The trouble with software, though, is that you cannot test it for durability. Where mechanical and electro-mechanical components can be tested to achieve reliability figures, you cannot attach a number to software reliability because it's basically a design."

According to Claas Bracklo, who is responsible for electronics integration in vehicle development at DaimlerChrysler, "Despite simplifications in the assumptions we made, we arrived at the figure of 10 to the power of 180 potential test conditions for a single vehicle model. If you wanted to examine all these as a simulation, you'd have to book several decades of computing time on a Cray supercomputer."

"There is also the challenge of hardware/software integration and the integration of modules to the vehicle," says Ward. "Automakers are moving to standardize CAN functions and so, in theory, all modules will run the same software, but the auto industry is not there yet. There's also the perception that software can easily be changed, leading to late changes being demanded by the client. However, if part of the software in a network has been upgraded, it does mean that it needs to be checked to ensure that it is still compatible with the rest of the network, but this does not always happen. In the past, electrical problems in a vehicle were typically centered on connectors, but the use of CAN buses has reduced interconnects in the wiring harness, so reliability should be improved. It is because electronics are taking over so much more of the vehicle's functionality it means that failures are more visible than ever before."

Another factor is there is a far less tolerance to faults as there is an expectation that a vehicle will be perfect for at least the first few years of its life. "The reaction to failure is now stronger and more emotional than ever before," says Oates, "However, vehicles nowadays are being developed in tighter timescales which means less testing and sample builds so the whole vehicle testing program is being compressed. This can lead to problems, especially when it comes to the interaction of electronic units on a car."

"In the past we didn't pay enough attention to these interactions among the different systems," says Stephan Wolfsried, head of the electrical/electronic systems and chassis unit at DaimlerChrysler's Mercedes Car Group. "To be able to meet this challenge, we need new tools that measure up to the requirements of a zero-defect culture. The notion that bugs in the software are unavoidable is mistaken as far as I am concerned." As a mechanical engineer Wolfsried believes any tolerance for defects is misconceived, and opens the way to careless and even negligent work on the part of the software designers. He uses a rating system called the "Capability Maturity Model for Software" developed by Carnegie Mellon University in the U.S. for assessing the quality of software manufacturers. In this rating system, the degree of maturity of the development processes at a software maker is assigned to one of five quality levels in a certification procedure based on defined evaluation criteria. Level 1 is the lowest level, and companies certified as Level 5 produce software of the very highest quality.

"We're having our software vendors undergo these certification processes, and we're setting the highest standards in the selection of our partners," says Wolfsried. "We have to present the car as a package in which everything has been correctly dealt with and the driver has nothing to worry about. We also have to guarantee the reliability that's promised and expected. That's what we're doing, and we're going to promote this philosophy among all the automakers, hardware manufacturers and software developers worldwide."

By William Kimberley, Editor

Automotive Engineer, London, [e-mail]