Like this - to be a software developer for cars. Part 1/2

Facing the realities of the engineering industry, most software developers do not cope - the products that we have to work with are very highly specialized. This is not the creation of programs for Internet users, computers or even mobile applications, and therefore beginners feel like Thomas from the movie "Running in a Maze". Look at approximately 50 seconds of the trailer and you will understand the shock of those who are dealing with the development of software for cars for the first time.

All you have is a variety of terms and tools that you have no idea about. When, during an interview at a car company, I asked what IDE they were using, the interviewer didn’t like my question, to put it mildly. I got used to Visual Studio, and naively hoped that here for the development of embedded software, we would need something similar. I had no idea what awaited me! Just a sea of ​​small and serious (in complexity) tools that needed another victim.

Moreover, when it comes to developing software for cars, tools are not the only problem. It is almost impossible to find literature for beginners or simply educational materials relating to libraries or the architecture of relevant programs. The term “study guide” does not sound appropriate at all, because the automotive industry is a very closed community. Yes, and the community can hardly be called, because with such a competition, no one should guess how you create this or that program. To learn at least something about the individual tools and mechanisms of this programming segment, you can sign up for exorbitantly expensive courses, but your company should be ready to pay a considerable amount and take at least several weeks to get the experience you need now. It is a pity that it is so difficult to understand the specifics of programming for the automotive industry, and therefore I decided to devote my article to this particular topic.
')
Since I repeatedly had to switch from creating applications for Internet users / computers to developing embedded programs and back, I know firsthand about the problems faced by newcomers who deal mainly with the first block of products. Similar difficulties arise for programmers who have never encountered the specifics of the automotive industry.

In this and the next article I would like to talk about the principles of operation of embedded programs for cars, as well as look into the depths of the exotic architecture of embedded applications.

What topics will we cover?

• How does embedded software improve car performance?
• How do embedded applications allow you to drive a car?
• What are some typical CPU limitations?
• How does the process of continuous processing of data from sensors take place thanks to the built-in programs?
• How is this software structured and how do separate applications interact with each other to drive a car?

I will answer these questions by looking at a specific example, and at the same time I will review the development of the firmware architecture. As an example, we take a fully electronic steering system. This is not a real model, but in structure it is, in principle, similar to what you most likely saw in your car. We will talk more about the architecture, and then proceed to a simplified scheme that reveals the essence of the system's functionality.

You can watch a video dedicated to the development of an electronic steering system. By the way, I also worked in this team.



This model is partially controlled by software. Partly means that specialized software only helps the driver, but he has full control over the system.

Suppose we need to create a fully electronic steering system in which the steering wheel is not directly connected to the wheels. Instead, the sensor measures the steering angle and sends the data to our program. In automotive terminology, this is a servo drive. You will not believe it, but thanks to Nissan, a servo model has already appeared on the market.

The software is provided by a tiny processor or, more precisely, a microcontroller connected via a network to a sensor.



When the driver turns the steering wheel, thanks to the sensor, which constantly transmits information about the current angle of rotation, the software receives the appropriate signal. For example, if the driver turns the steering wheel 90 ° to the right, for a second the sensor signal is processed according to the following principle:



In addition, the software also controls the operation of the electric motor, which moves the toothed rack from left to right and in the opposite direction, which means that the angle of rotation of the front wheels of the car changes. Accordingly, the software can steer the car left or right. The connection between the microcontroller that runs the software and the electric motor is provided by an electronic control unit (ECU), which includes the microcontroller itself and a power amplifier that regulates the engine's power supply system. Thus, our program varies the current supply in the motor and the position of the rack changes in the right direction.


Electronic Control Unit (ECU)

Provided that the firmware is working correctly, when you turn the steering wheel, the position of the toothed rack changes almost instantly.


Steering wheel - blue, steering rack - pink (approx.)

It becomes clear that even the processing of information here does not obey the logic of event-oriented programming, as is the case with the usual applications of the graphical user interface, nor the laws of batch files. Instead, continuous, timely processing of incoming data is required. If it takes too long for the program to analyze the sensors, the steering rack and the front wheels of the car will move with a delay, and the driver will notice. Most likely, in an extreme situation, this will lead to a loss of control over the car , for example, when you turn the steering wheel in order to avoid obstacles, the car will not immediately react to the maneuver. This specificity increases the requirements for the time indicators of programs for automobiles, especially if one considers the limited processor performance of standard electronic control units.

In continuation of the series, we will look at the software architecture that allows us to eliminate the indicated problems, and, I hope, with the help of these materials, novice developers of embedded applications for automobiles will more quickly master the basic principles operating in this field.

Part 2/2