University of York – Real time vehicle control

03-title

Imagine you’re in your car. You approach the traffic lights, and put your foot on the brake.

At this point, your brake lights go on and you slow to a stop. But there’s a lot more going on than that.

Pressing the brake closes a switch, which is detected by an Electronic Control Unit (ECU). The ECU passes a message over a Controller Area Network to another ECU at the back of the car. The message is then decoded, and causes the brake light to turn on. All of this happens in a fraction of a second.

Now imagine similar events and responses happening hundreds of times a second throughout your car, controlling everything from gear changes to fuel injection and ignition timing. Oh, and there’s a time limit for pretty much every one of them.

Image of Alan Burns

Alan Burns

Over the last 25 years, under the guidance of Alan Burns and Andy Wellings, the Real-Time Systems Research Group at the University of York has been finding ways to make this system more efficient, more reliable and less memory-intensive. Its areas of research have sparked three separate start-up companies, and been used by automotive and aerospace companies worldwide.

Each strand of research represented a different challenge for the team, but helped to make vehicles work more efficiently and reliably as a result.

Image of Andy Wellings

Andy Wellings

Let us begin with Controller Area Network (CAN) mentioned earlier. Before the 1990s, cars were fitted with point-to-point wiring, which was expensive, difficult to maintain, and left cars clogged with a heavy jumble of wires. For example, connections to a door in a high-end car required more than 50 wires.

As vehicles became more complex, CAN was devised to handle communication between Electronic Control Units (ECU) digitally, reducing the need for wires in that door from fifty to just four.

With CAN, messages are broadcast to all of the ECUs on the network; however, the number of ECUs keeps on rising. Whereas a mid-nineties car would have 5 to 10 ECUs, modern cars may have as many as 70. So now message traffic is an issue, and every message has an important deadline to meet.

In 1994, Ken Tindell, Alan Burns, and Andy Wellings introduced a different way to think about this potential log-jam. Using an approach known as schedulability analysis, they enabled designers to work out offline if all of the messages on the network could meet their deadlines. They did this by computing the longest possible time that each message could take to go from being queued by one ECU to being received by another.

After publishing their research, they were approached by Volvo Car Corporation. Two members of the group, Ken Tindell and Rob Davis, formed a start-up company Northern Real-Time Technologies to capitalise on the work.  Along with a Swedish company, they developed what became known as Volcano technology.

“Before this analysis was done, there wasn’t really any way to test how long a message could sit there in the queues”, says Rob Davis. “We provided a scientific method to analyse this offline and find the maximum time each message could take to be sent over the network.

“You used to have a network that you could only run at 30% capacity before messages started missing their deadlines. With our approach, focused on using the correct priorities, we pushed that up to 70% or 80%.”

03-3 03-4

Volcano technology has been used in Volvo cars since 1997, and was added to the Ford Premier Automotive Group range after Ford bought Volvo in 1999. That meant it found its way into Jaguars, Land Rovers and Aston Martins as well. Today the Volcano technology is owned by Mentor Graphics.

Following their success with Volcano, Ken Tindell and Rob Davis set up another venture, Northern Real-Time Applications, focused on developing a real-time operating system for the low cost microprocessors used in ECUs. This work again capitalised on results from the Real-Time Systems Research Group, including research by Neil Audsley, Alan Burns and Andy Wellings on operating system design, processor scheduling, and response time analysis.

The two biggest pressures on the processors used in ECUs are processing load and memory use, while the biggest concern is cost.

“Memory on these processors is extremely limited”, says Rob Davis. “If you can use less memory, you can get individual microprocessors at slightly lower cost, and across a production run of a million or more cars that adds up to a big saving.”

“We started by realising that the functionality needed in a real-time operating system could be really quite basic. It needed to support the dispatching and running of tasks, and the sharing of data between them without that data being corrupted. We made sure that you didn’t have things going on in the operating system that didn’t need to be there. Effectively the operating system was tailored to the precise needs of each application”.

“The size of the code for the operating system is extremely small, about one and a half kilobytes, so small you can print it on a coaster.”

The company gained £1m in venture capital funding in 1998, and a further £9.2m in 2000, changing its name to LiveDevices a year later. Robert Bosch subsidiary ETAS bought the company in 2003, taking over the team of 20+ engineering staff.

“ETAS had their own operating system, and found it was not as efficient as the one we’d produced”, says Rob Davis. “They could either start again from scratch or buy the company”.

Since then ETAS have updated the operating system (RTA-OS) to the AUTOSAR standard and adapted it to work on more than 25 different microprocessors.

It has been used in about 1 billion ECUs by most of the world’s leading car companies and their major suppliers. The total goes up by between 1 and 2 million per week. It’s the world’s smallest and fastest automotive operating system.

Research by the University of York’s Real-Time Systems Research Group has reached further in recent years. Building on their industry knowledge, Guiem Bernat, Ian Broster, Antoine Colin and Rob Davis started a company called Rapita Systems in 2004 whose products give companies in the aerospace, automotive and space sectors more confidence that their systems will meet their timing requirements.

In these industries, if software takes longer than anticipated to execute, it can lead to issues with reliability or worse.

Using technology known as RapiTime, engineers are able to determine the longest time that each software component can take to run, called the Worst Case Execution Time, and budget accordingly. Previous approaches either tended to underestimate this Worst Case Execution Time, or required costly updates to the analysis tools for each new processor.

RapiTime was first evaluated on a system provided by Audi, and was used on BAE Systems’ Hawk Advanced Jet Trainer project in 2006. The technology enabled BAE Systems to reduce the Worst Case Execution Time by 23%, by helping them identify the 1% of the code that was causing the bottleneck.

RapiTime technology has led to the creation of a number of high technology jobs in York, and is used in space, automotive and aerospace projects across the globe that would otherwise have to rely on manual measurement and analysis.

As one major aerospace supplier says: “Not only did we reduce our effort requirements for the testing, but we could use our results in ways that were infeasible before. It is now significantly faster for us to identify a timing issue, update the software to resolve the issue, test the updated software and verify that it’s fixed.”

As the automotive and aerospace industries develop new and more complex products, correct timing behaviour is crucial. A quarter-century of research and experience at the University of York has helped them be more confident that their systems will meet their deadlines.

“We’ve seen a huge revolution in electronics over the years, with significant improvements in reliability as well”, says Alan Burns, current head of the Real-Time Systems Research Group, “It’s great to know that our research has had a hand in it.”

Links to Additional Information

Real Time Systems Group, York University

CAN Bus

03-main

Naomi AtkinsonCase Study
Imagine you’re in your car. You approach the traffic lights, and put your foot on the brake. At this point, your brake lights go on and you slow to a stop. But there’s a lot more going on than that. Pressing the brake closes a switch, which is detected by an...

You might also like to read:

Case Study

University of Hertfordshire – Robot-assisted play therapy for autistic children

Case Study

University of Brighton – Dictionary Production

Case Study

Cambridge University – Payment systems