How to be an automobile software engineer — Part 4
Scheduling and the truth about being an automobile developer
Our endeavor to build a Steer-By-Wire system has come almost to an end. In part 1 we set the system up and dived into the software architecture in part 2. Part 3 gave you a glimpse of the microcontroller constraints.
In part 2 of this series you guys saw that the software architecture of our Steer-By-Wire system aligns to the rhythm of the bus communication.
That enables us to react timely to changes of the steering wheel position but also makes the steering behavior worse than needed. The front wheels will judder according to the next diagram when we stay with this software architecture. This diagram shows how the PWM output looks like if it will be synchronized to the incoming bus messages.
So how can we improve the steering behavior and make turning the front wheels smoother?
When you open yourself to the PWM stepping diagram the solution will pop-up by itself. We need smaller steps! That is the system shall calculate the PWM more often than receiving bus messages. You can divide the solution to that problem into two parts: one is scheduling and another one is PWM value. Determining the PWM value is an art of itself and I leave that to control engineers. But scheduling is something an automobile software architect should care about.
How does RTOS scheduling work?
A cyclic task with a higher frequency than the frequency of the incoming bus message will solve that problem.
Since I mentioned a cyclic task we get into how an automotive RTOS works. A task is some functionality that is scheduled by the OS. It’s somehow similar to a process or thread. An RTOS is a Real-Time Operating System. The most prominent automobile RTOS standard is Autosar OS. Autosar is a standard for the software architecture of automobile embedded software and is more concerned about small systems compared to PCs or even mobile devices like smartphones which run operating systems like Linux or Windows. Many things you would expect to be part of an OS when coming from those large OS’s is standardized outside of the OS. So an Autosar OS is mainly concerned about scheduling, task synchronization (e.g. with event mechanisms), memory protection and timing protection. That’s all, broadly speaking.
Autosar standardizes much other stuff outside of the RTOS. There are different kinds of drivers for communication, memory usage, PWM, Analog-Digital converters and so on. There are also communication mechanisms for tasks but they are not part of the RTOS.
Timing considerations
In principle, tasks may run in a cooperative or a preemptive multitasking mode. Cooperative multitasking means that a task cannot be interrupted by another task. You know that it will run from start to end almost without interruption. I say almost because hardware interrupts are an exception. But inside of a cooperative task, you don’t have to worry about data consistency and you can examine how much time it will take until it’s finished. And the latter point is crucial for safety-critical systems like our Steer-By-Wire system. There you need to be sure that the PWM output is not too much too late or that an error-detection function realizes soon enough that our steering system does something wrong. We talk about milliseconds in these examples and not about seconds.
Coming back to our PWM smoothing challenge we set up 2 tasks:
Task 1: Com and Steering triggered by an incoming message
Task 2: PWM calculation and output triggered by a timer
As you all probably have figured out plotting the scheduling onto a timing diagram will look like this:
In the above diagram, you can see that the tasks (blue) are triggered by different mechanisms. One is the FlexRay message event and one is the timer event. The timer triggers e.g. every millisecond the PWM calculation task (blue). The green PWM plot depicts the electrical PWM output.
Let’s assume we know how to calculate the PWM value for every task run our PWM output plot will be smoothened:
Depending on the frequency of our PWM task we get different step sizes. This is what you see in different colors in the plot. It’s crystal clear that the wheels of our car will stop to judder when the PWM output frequency is high enough. The ideal frequency is determined by experiments. I depict this in the next drawing where you can see the effect of different frequencies on the wheels.
I want to give you an impression of my and other’s real work. Therefore, I show you some diagrams that were created in real projects.
The actual scheduling and timing can be measured in real-time on the ECU with some debuggers or with a specialized tool like T1.
I used its predecessor traceGuru (unhappily fun like this product name is really rare in the automobile industry) a lot in order to see if we met time limits and to watch the CPU load in certain situations.
So now you have seen an example of embedded software architecture and how features of an automobile RTOS are used to affect a car driver’s experience. Cyclic execution of tasks fits well to repeatedly receiving messages and controlling electrical devices like motors. By splitting tasks into several tasks running with different frequencies or cycle times we achieved an acceptable behavior of our Steer-By-Wire system.
There is much that could be said about how to handle more complex scenarios regarding task scheduling, data flow and software architecture in general, but most probably that would be hard to comprehend by just reading an article. You would have to invest a lot of time to get to know all those details. That’s the same as in every other software development domain. In the end, you would need to practice it.
The reality of the automobile industry
I gave you some insights into embedded automobile software developer mindset based on a fictitious Steer-By-Wire system. Developers who love to dive deep into technical details and who love challenges with tough constraints could find interesting tasks in automobile software development. I also had times when I was excited about building such systems with some great colleagues.
But the sad truth is that the automobile industry has still huge difficulties in understanding how software development works and is lost somewhere in extremely heavy-weight processes that hinder the development of high-quality software. The intent of those processes is to produce high-quality products but they are contrary to the insights of the software development industry. Many things that were proved not to work and were abandoned in the software development discipline 10 to 20 years ago are still considered a must. Even if they experience in a day-by-day manner that it does not work. The reasons for that are so multifaceted that it’s almost impossible to write about it.
If you consider joining an automotive company you should know that often hundreds of developers are working on one part of a car. That’s my insight and I got the confirmation when I attended an automobile developer conference in Stuttgart, Germany, home of Mercedes and Porsche, last year. Many big and not so big car suppliers came together and gave insights into their development processes. Most of them have really huge development organizations comprised of software developers, testers, requirements engineers, architects, integrators, QA people, safety engineers, problem managers, software project managers, technical project managers, line managers and many more persons of other engineering disciplines. And that’s the organization for the development of only one system like brakes or a steering system. To complete the picture these organizations develop a lot of variants of the “same” system for different car models. As a result, many of the developers are busy with the adaptation of existing solutions.
Therefore, you should not expect to get a lot of room for creativity and independent work. Rather you should anticipate a lot of paperwork. That will occupy your time much more than writing code.
I talked about my experiences and my observations at the Developer on Fire podcast. That is if you want to hear more about it listen to
As always I am looking forward to hearing from you here at Medium or at Twitter.
Thanks to Marcel Medak for giving feedback to my blog posts!
