Which topics will be considered?

How does the embedded software augment what happens with the car?

How does the embedded software control a car?

What are typical CPU constraints?

How does the embedded software application process continuous data from sensors?

How is the software structured and how do the individual pieces collaborate to control the car?

I will answer these questions through a concrete example and want to guide you by developing the software architecture of an embedded software application. The example will be a fully electronic steering system. This steering system isn’t real but architecturally similar to the steering system that you would most probably find in your own car. I will concentrate on the architecture and therefore will over-simplify the actual steering functionality.

You can watch an interesting example of an electronic steering system developed by a team I have been part of.

An example of a steering system partially controlled by software

This example steering system is partially controlled by software. Partially means that it supports the driver but the driver has the ultimate control of steering the car.

Developing a car steering system in a sandbox

Let’s assume we want to develop a fully electronic steering system in which the steering wheel is not directly connected to the wheels. Instead a sensor measures the steering wheel angle and sends it to our software. The automotive term for this would be Steer-by-Wire. You won’t believe it but Nissan has already brought a car with Steer-by-Wire to the market: http://www.caranddriver.com/features/electric-feel-nissan-digitizes-steering-but-the-wheel-remains-feature

The software runs on a tiny CPU or to be exact a microcontroller which has a network connection to the sensor.

When the driver turns the steering wheel the software gets to know about this through a steering wheel sensor which sends continuously the current angle of the steering wheel. E.g. when the driver turns the wheel 90° to the right in 1 second the sensor signal will proceed as in the following diagram.

On the other end the software controls an electrical motor that moves the steering rack from left to right and vice versa changing the angle of the front wheels of the car. This way the software is able to steer the car to the left and right side. The connection from the microcontroller running the software to the electrical motor is established through an electrical control unit (ECU) containing the microcontroller, and a power stage that controls the power supply of the motor. This way the software is able to control the electrical current that a motor needs to move the steering rack.

Assuming the software is finished and working correctly the position of the steering rack would follow the movement of the steering wheel almost instantly.

It gets clear that processing this data is not event driven like applications with graphical user interfaces or even batch-driven. Instead the input values must be processed continuously and in a timely manner. When the software needs too much time to process the sensor data, the steering rack and the front wheels of the car will follow with a delay that the driver will recognize. Most probably the driver will loose control over the car in an extreme situation e.g. if he wants to avoid an obstruction at the street and the car movement does not immediately react to his steering attempts. This scenario of course burdens hard timing requirements onto the software especially with regards to the very limited CPU performance of a typical ECU in the car.

The next parts of this series will elude the software architecture that solves these problems and will hopefully help aspiring software engineers to get a clear understanding of the principles behind embedded software architecture.

I am looking forward to answer your questions.