As car designers compete to pack more electronics into their vehicles, they are also having to focus on the issues of safety and security.
In February this year GM decided to recall more than two million vehicles after finally tracing a serious problem with its cars to a weak spring in the ignition lock. If the key swung too far it could disable the engine and not just cut the power, but put out of action the electrically assisted brakes and steering.
Over the years, automatic-transmission vehicles have suffered problems with sudden acceleration where for no apparent reason, the car simply speeds off. The cause of a number of incidents with Toyota vehicles remains unsolved although, where driver error has been ruled out, suspicion has fallen on the electronic controllers possibly running out of memory temporarily or getting confused by sensor inputs.
It is a critical time for the automotive industry. Governments around the world have decreed that roads need to be much safer and the key lies in the car itself, ultimately to the point that the vehicle takes over responsibility for safety. Research into self-driving cars by companies such as Robert Bosch and Google anticipates a point in the future when governments consider cars to be safer when they drive themselves.
It could be decades before self-driving cars are the norm on public roads. They are being introduced in places where the vehicles can be segregated from other users, and computers are gradually taking more control. The long-term trend is towards steer-by-wire and brake-by-wire systems that allow electronic control units (ECUs) to control how the vehicle moves. They will work with advanced driver assistance systems (ADAS) that use a combination of video cameras, radar and other sensors not just to warn drivers of potential problems – such as drifting out of lane - but to keep the car on course.
Electronics are beginning to replace the mechanical systems, such as hydraulic brake cables and the direct link between the steering and the wheels. "Today's automotive systems are effectively fail-silent," says Stefan Singer, automotive field applications engineer at Freescale Semiconductor. "The system shuts down but there is a mechanical fallback. If ABS shuts down, you still have the braking you had. We are about to lose that mechanical fallback. The system moves from fail-silent to fail-active, where we need to ensure that the [electronic] system at least works in the limp-home mode."
As well as increasing the number of safety systems, carmakers are trying to keep abreast of the rapid changes in consumer electronics, which often use devices made on much newer, less well-tested process technologies than those qualified for automotive use using standards such as AEC Q100.
"If the customer wants LTE [devices] in the car, we have to find ways to use them in cars," says Berthold Hellenthal, head of the semiconductor programme at Audi. The result is a massive increase in the complexity and number of electronic devices that make it into the vehicle.
Rise of new car systems
"Electronics content is expected to be about 50 per cent of the value of a car within this decade," says Andrew Patterson, business development director at Mentor Graphics, which supplies both software and hardware-design tools to the automotive industry.
Michael Bolle, president of corporate R&D at Robert Bosch, says: "The automotive industry has to become much faster at adopting technologies. Automotive, consumer electronics and IT technologies will converge. Product lifecycles will have to become much faster."
Because consumer technologies are likely to change faster than the car replacement rate, Bolle says the vehicle needs to adapt. "We aim to make the elements of the system reprogrammable. We want to bring new software into the field without bringing cars out of the field into the dealerships."
Patterson adds: "Old systems were pretty much hardwired into the car. Dashboards are now being designed to be reskinned, so they can go to 'race mode' and other designs."
To accommodate possible changes, Bosch and other companies are looking to use more powerful processors up front. Bolle says: "Rather than optimising for cost, bring some headroom into the design and use that for reprogrammability." That in turn brings additional issues: "The problem for hardware upgrades is the huge amount of work you have to do to validate the design."
Although attaching an LTE phone to the car's systems should not make a difference to safety, technological trends mean the consumer and core vehicle functions will become intimately connected.
Glenn Perry, general manager of the embedded systems division at Mentor, says silicon integration makes it possible to put multiple functions onto the same chip. A controller behind the dashboard needs to ensure the driver's key information displays remain up to date while handling less important video for passengers. This will require software to isolate the parts of the system that conform to different levels of criticality.
Some of those processors might be called on in the event of a failure of the main safety-related system to provide backup by loading different software. So, what was not a safety-critical system for most of its life will suddenly become one to allow the driver to get home, even if it's not at top speed.
"We see a tremendous move towards combining systems where you have [different levels of safety] on the same PCB or SoC and keep the same development flow across the engineering teams," says Rainer Oder, managing director of automotive systems house XS Embedded.
Staying on track
Amid the growing complexity, the industry has failed to determine the definitive cause of sudden acceleration. GM's engineers apparently did not analyse the full consequences of turning off the ignition on the vehicle's electronic systems.
At the micro level the decisions made by the onboard computers made sense. If the car was no longer running, why would it need steering or braking assistance?
The problem lay in the combination of those decisions at 65mph on a US freeway. The system knew it had to respond to a change in conditions. Mistaken assumptions about that type of change led to a highly inappropriate response.
Can the automotive industry do better? To a large degree, manufacturers are placing their faith in a standard published in 2011 by the International Standards Organisation (ISO) that has had significant input from safety experts at carmakers such as Jaguar Land Rover. ISO 26262 is rare among safety standards in that no government has demanded its implementation. But vehicle manufacturers were swift to adopt it.
The approach taken by ISO 26262 should lead to safer systems, as it focuses on issues at the system rather than the component level. But for the manufacturers the standard has one other important, almost talismanic effect. After publication in 2011, lawyers advising the industry argued that ISO 26262 represents part of the state of the art for developing safe systems. This has important ramifications when it comes to product liability. If a vendor with a faulty system can demonstrate it followed the state of the art, it can avoid liability on the basis that no other vendor in the same position is likely to have developed a safer system.
The standard itself accepts that "absolute safety is an unobtainable goal". Its aim is to help manufacturers build the evidence to "demonstrate that the system is free of unreasonable risk". And manufacturers are building up a lot of evidence.
Jim Buczkowski, director of electronics and electrical systems engineering at Ford, says: "It's similar to other ISO standards: it's about a repeatable, traceable, well-documented process. You need to ensure the decisions you make are supported by data. It's a daunting task. A lot of work has to go into applying it. I don't think there is anything that guarantees a perfect system but if you have a repeatable and traceable process you can employ process to assure the best outcome."
Safety forcing function
Noah Reding, product manager for automotive and aerospace networks at National Instruments, says: "One of the key elements of ISO 26262 is that at every stage you need to tie back what you are doing to safety requirements. Those requirements become critical. It is a sort of forcing function. Engineers don't just look at it from a functional perspective but also a safety perspective, and the team has to verify that it satisfies the safety requirements. It's promoting good habits, particularly in systems engineering."
Singer agrees: "Typically, ISO 26262 has a nice approach. It is about safety within the context of the function. There could be faults happening that you don't care about. And others that could have a dramatic effect, where electronic steering is affected, for example."
The drive to adopt ISO 26262 is putting downward pressure not just on the subsystem suppliers who sell to the carmakers – the 'tier ones' in automotive supply-chain jargon – but also the companies that provide components and software to those suppliers.
"ISO 26262 requires us to create endless amounts of documentation for the design process," says Singer.
Reding says: "I think there are a lot of areas where ISO 26262 will affect the supply chain. Where it's really forcing in the industry is in the way it's bringing about a very detailed conversation between suppliers and OEMs: who is going to do what and what an actual function is. An OEM may think they are being specific with their requirements.
"Because the supplier is now thinking about how all that maps to requirements and safety requirements they are now being more rigorous. That will certainly promote the use of model-based design tools to help communicate specifications and the use of more qualified tools on the test and verification side as well," Reding adds.
Models and simulations are becoming the key way in which these systems are tested not only for their safety credentials but to demonstrate how they will work. These simulations have evolved into complete virtual prototypes where the functions of the car live within one or more computers.
Buczkowski says: "The differentiation is now in the software. It took a while for a lot of automotive folks to understand that. The more we can do in modelling and present a proof of concept that doesn't require something to be built physically the faster we can make trade-offs. It is very difficult to design these systems when there are so many systems talking to each other."
Rather than putting test drivers at risk in real systems, carmakers inject errors at will into the virtual prototype to see what the effect will be on the rest of the system. If the engine stops, its knock-on behaviour on other systems can be tested to see if their response makes sense.
"Whenever someone says ISO 26262, you need to introduce test patterns of certain kinds and inject certain errors," says Frank Schirrmeister, senior director at development tools supplier Cadence Design Systems. "It's much better done with something that you have tight control over, which tends to be simulation."
A traditional requirements-driven development process typically follows a V-shaped pattern in which the requirements are created at the beginning not just to help drive development but test. As development proceeds, the projects moves down the left arm of the V, generating module-level test routines on the way. As the system is integrating into its final form, the process moves up the right arm to the point where it can be tested in its entirety against the full set of requirements.
Companies such as Jaguar Land Rover are moving over to a double-V process. Rather than using a traditional V software development process from concept to system integration and test, the motor company does virtual integration and test, where failure modes can be safely analysed before moving onto the second V, where real hardware is swapped in gradually.
"They are connected to a physical system but the test stimulus, data logging and control model that all stay the same [as in the virtual prototype]. If you can use a software environment that lets you swap in models for physical systems you don't have to invent the wheel each time to perform the tests," says Reding.
The problem with simulation is that it takes time to capture all possibilities, and this may not be enough to support the shift to autonomous driving.
Bolle says: "With autonomous driving new questions arise. To do automated braking you need a certain amount of validation. We have looked at what it takes to validate autonomous driving, and the time needed was estimated at 100,000 years. We need breakthrough solutions from the research community."