 Software-based 7
| 'Middleware' explained with a practical example. |
kfz-tech.de/YSD5
We are picking up almost seamlessly right here. Just imagine for a moment that you have a soap dispenser in your bathroom that tilts into the washbasin every time you need it and
has to be “repaired” before you can use it again.
'
In that case, surely you wouldn't consider buying just a new soap dispenser. The solution seems to be to mount the next one on the wall, doesn't it? Can you realize, the concept of “middleware' is exactly that kind of partial
solution to a much bigger problem.
Yes, as the name suggests, it's right in the middle of it all. And the problem it solves is quite similar to that of the old soap dispenser. It's the struggle with hardware that every programmer who has to work closely with
hardware has to face.
Let's get comfortable and, this time, take an example from the early days of computer technology. Konrad Zuse's first computer required punched holes on 35-mm-wide film reels just to understand the problem it was
supposed to solve.
With the second, Alan Turing’s revolutionary machine, bits could already be entered at the push of a button. The result was then also displayed in bit form. It must have been a huge relief to be able to enter entire bytes or
even hexadecimal numbers.
However, when it came to programming, you still had to think of commands in terms of numbers that the computer could understand. It was only with the advent of compilers that it became possible to move away from pure
machine language. People began to understand what they themselves or others had programmed there.
No, we won't go on to describe modern programming languages just yet; instead, we'll simply note that there are ways to write programs without having to worry about the specifics of the underlying
hardware. You can surely imagine the benefits.
But cars today aren't just equipped with sensors and actuators; they also have controllers, drivers, timers, buses, and memories, and these components need to be addressed repeatedly throughout the course of a
program being developed. How nice that would be, to be able to turn a blind eye to them.
And that is exactly the bridge that the middleware builds for the programmer. But of course, it doesn't just offer benefits to this group; it also makes interchangeability significantly easier. Hardware
and middleware change, but application software does not.
By the way, automotive middleware already existed back then, even though no one had even thought of the software-based car yet, even though it is a software-based level. Middleware became all the more necessary as
systems in the car
This led to the development of CAN, LIN, FlexRay, and Ethernet for the automotive industry in the area of connectivity. An Ethernet protocol is, for example, Salable Service-Oriented
Middleware over Intergrated Platform. IP is therefore a platform that enables data exchange between applications.
While in-vehicle networks are indeed fast, with the Data Distribution Service, one enters the realm of extremely low latency and response times. There is no master here, referred to as a 'broker'.
Take, for example, the exchange of data prior to decisions regarding autonomous driving.
Message Queung Telemetry Transport is all about connecting to external systems, such as a cloud or Over The Air. It is
indeed broker-based, but is considered 'lightweight', meaning it requires relatively little overhead. Unlike DDS, it is not capable of real-time processing.
| A system is considered real-time capable if it produces results within a specific, predetermined time
frame and if that time limit can always be relied upon. |
Finally, there is Diagnostics over IP. Ethernet, a faster data transmission system than CAN bus, allows repair shops to analyze faults more quickly and even perform the kind of analysis that is now
typically carried out by the manufacturer on vehicles in the workshop.
| 
