Software developer for cars.

  • click to rate

    Faced with the realities of the machine-building industry, most software developers do not cope - they have to work with highly specialized products. This is not the creation of programs for Internet users, computers, or even mobile applications, and because of this, beginners feel like Thomas from the movie "The Maze Runner". Watch about 50 seconds of the trailer - and you will understand the shock experienced by those who are dealing with the development of software for cars for the first time.

     

    All you have is a set of terms and tools that you have no idea about. When, during an interview at an automobile company, I asked what kind of IDE they use, the interviewer did not like my question, to put it mildly. I'm used to Visual Studio and naively hoped that something similar would be needed here for developing embedded software. I didn't even imagine what was waiting for me! Just a sea of small and serious (in terms of complexity) tools that needed another victim.

     

    Moreover, when it comes to automotive software development, tools are by no means the only problem. It is practically impossible to find literature for beginners or simply training materials related to libraries or the architecture of the corresponding programs. The term "teaching manual" does not sound appropriate at all, because the automotive industry is a very closed community. And you can hardly call it a community because, with such 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 segment of programming, you can sign up for extremely expensive courses, but your company must be ready to spend a considerable amount and it will 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 automotive engineering, and therefore I decided to devote my article to this very topic.

     

    Since I've had to switch from creating applications for Internet users/computers to developing embedded programs and vice versa, I know firsthand the problems faced by beginners dealing mainly with the first block of products. Similar difficulties arise for programmers who have never encountered the specifics of the automotive industry.

     

    In this article, I would like to talk about principles of work of built-in programs for cars, and also look into the depths of the exotic architecture of built-in applications.

     

    What topics will we consider?

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

     

    As an example, we will take a fully electronic steering system. This is not a real model, but in terms of structure, it is, in principle, similar to what you have most likely seen in your car. We will talk in more detail about the architecture, and then we will move on 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. It partially means that the 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 angle of rotation of the steering wheel and sends the received data to our program. In automotive terminology, this is a servo drive. You won't believe it, but thanks to Nissan, a model with a servo drive has already appeared on the market.

    The operation of the software is ensured by a tiny processor or, to be more precise, a microcontroller connected to the sensor via a network.

     

    In addition, the software also controls the operation of the electric motor, which moves the gear 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 direct the car to the left or right. Communication between the microcontroller, which runs the software, and the electric motor is provided by the electronic control unit (ECU), which includes the microcontroller itself and a power amplifier that regulates the engine power supply system. Thus, our program varies the current supply to the engine, and the position of the toothed rack changes in the desired direction.

    Provided that the built-in software works correctly, when turning the steering wheel, the position of the gear rack changes almost instantly.

     

    It becomes clear that even the processing of information here does not obey the logic of event-oriented programming, as in the case of familiar graphical user interface applications, or the laws of packet files. Instead, continuous, timely processing of incoming data is required. If the program needs too much time to analyze the sensor indicators, the steering rack and front wheels of the car will move with a delay, and the driver will notice it. Most likely, in an extreme situation, this will lead to a loss of control over the car, for example, when turning the steering wheel to avoid an obstacle, the car will not immediately react to the maneuver. Such specificity increases the requirements for the time performance of programs for cars, especially if you take into account the limited performance of the processor of standard electronic control units.