Interview with Joachim Schlosser

Dr. Joachim Schlosser leads a team of computer scientists and engineers at Elektrobit Automotive who advise car manufacturers and automotive suppliers on topics such as agile development methods, functional safety and autonomous driving. He is also known for his bloghis work for MathWorks (MATLAB/Simulink) in teaching, as well as his textbook on LaTeX.

Between the years, I had a conversation about modeling in teaching, autonomous driving and systems thinking.

You write on your website that you help professors and other teachers with MATLAB and Simulink. What exactly does that look like?

That's what I've been doing so far, but I stopped at the end of the year and started at Elektrobit Automotive Consulting at the beginning of the year. There I'll be even more involved in agile development methods and functional safety, as well as autonomous driving. These are topics that I have already been involved with in the past.

But what I have done so far, and what the MathWorks team will continue to do, is to advise teachers on how they can use MATLAB and Simulink in their teaching. This arose from the desire of many professors to use these tools, which they are often already familiar with from their industrial environment. They are then unsure whether it is not too difficult and to what extent it is compatible with the mandate to teach theory. At the same time, they also want to give the students practical relevance and are looking for approaches. They often approach MathWorks with these questions. In response, we then set up this Europe-wide team and traveled around the countries. We transferred knowledge from A to B, gave application examples from industry and connected people. The whole thing was always based on the idea that students find a different approach to the topic when they apply it themselves. All theory is gray, and the aha effect comes in practice: "Mathematics has to be like this, otherwise it won't work".

All theory is gray, and the aha effect comes in practice: "Mathematics has to be like this, otherwise it won't work" [tweetthis]All theory is gray, and the aha effect comes in practice (Joachim Schlosser)[/tweetthis]

This works wonderfully for mathematical things, such as control, regulation or signal processing. This provides a completely different approach. They learn nice things like Nyquist frequencies and the like. It's nice to be able to calculate something like that, but when I use it myself at some point and really see how the sampling rate affects the noise, and then I have to do this and that, then it suddenly becomes clear why you have to learn all this.

In other words, you help the educational institutions to bridge the gap between theory and practice.

Exactly. That's also the issue in teaching: we're told to teach students concepts and theory, not tools. But here I say: yes, at least at universities, it's not necessarily the requirement that graduates have knowledge of tools - but it's nice. And it's a different story at universities of applied sciences. Research groups also like it when people already know the tools - and industry anyway. But at the end of the day, the tool in teaching is also a tool to better understand the theory. So the tool should never be an end in itself.

The tool in teaching is a tool to better understand the theory [tweetthis]The tool in teaching is a tool to better understand the theory (Joachim Schlosser) [/tweetthis]

Or if the students learn modeling, then they can model Simulink at the end. But the main point is that they gain an understanding of the system: They learn that you have to understand a dynamic system as such, that you have to think about the structure, decomposition, system boundaries and relationships. In the process, I learn systemic thinking, often not explicitly. I also have to answer all these questions, which I would later have to answer as an engineer, when I am modeling. The tool does not allow prose, but forces you to answer these questions as precise inputs.

Of course, I like the system idea, as this represents a step up in terms of seeing the overall context.

This is also the bridge to my future work, which is about autonomous driving: I can't think at circuit level either, but have to move at system level, i.e. deal with topics such as system boundaries, interactions and the like. I can only get there with modeling.

Autonomous driving is certainly a good example of the relevance of my next question: How can mathematics help us to get a grip on systemic challenges such as complexity, non-determinism and safety?

The beauty of autonomous driving is that any object that can be described by the laws of physics moves through a world that can also be described by the laws of physics. But we can't start with Adam and Eve, we have to limit ourselves to what we really need, i.e. abstractions. Mathematics, and computer science in particular, has some great models for dealing with levels of abstraction. These help us to decide how far time, data or even calculation steps can be abstracted and what interactions exist. And in the technical model, there is of course a lot of mathematics in physical aspects such as trajectories, braking curves and the like, and of course in the perception of the environment. This is where it becomes problematic, as we saw last year with incidents in semi-autonomous driving.

... although some of these incidents were also caused by humans.

Yes, and that's certainly partly a marketing problem: if it says "autopilot" somewhere, people think it's autopilot.

I would like to revisit the topics of abstraction and encapsulation, which play a major role in languages such as SysML, for example, keyword scaling

I see ripples and trends in engineering and IT here. Sometimes people say: we build perfectly integrated systems where everything works together with everything else; that works well for a while until the need arises to verify it thoroughly. Then comes the hangover, and emphasis is placed on modularity with loose coupling, with syntactically and semantically clean interfaces. This then makes it possible to thoroughly verify the modules individually to ensure that they behave correctly in order to draw conclusions about the system as a whole. We've had two or three waves like this since I graduated. But I don't just see it as a wave, but also as an upward spiral.

That reminds me of my own doctorate, which was about the industrial suitability of architectural models. That was fine as an idea, but it doesn't work if the models don't correspond to the questions in terms of the level of abstraction. If the question asks one or two levels of abstraction more detailed than the model can answer, then it simply doesn't work conceptually. Since then, I've been wary when people want to develop a complete model. It is often unclear what the model is actually supposed to do.

If the question is on a different level of abstraction, the model cannot answer it conceptually (Joachim Schlosser) [tweetthis]If the question is on a different level of abstraction, the model cannot answer it[/tweetthis]

But that is a question that should always be answered: What is the purpose of the model? This often degenerates into actionism, and you can spend a wonderful budget on it, and you can also show a lot. But if I haven't formulated a sensible question beforehand that the model is supposed to answer, then the model is an artifact that is useless from a business point of view, and certainly not from a safety point of view.

Such projects also bring computer science and parts of engineering into disrepute.

Mathematics is also used through the use of calculi to establish a relationship between the levels of abstraction that can be proven under certain circumstances.

We have done this with Simulink in an industrial context both with model checking and with formal methods and provers, for example checking safety-relevant invariants. This also works quite well once it has been broken down to the algorithm. However, this only helps if the environment is also correctly recorded, for example the speed. As soon as the data is not reliable, even the best statement doesn't help.

What are your plans for 2017?

Of course, my new job means I'm working at full capacity. The challenge is: how do I introduce automotive manufacturers and suppliers to the topic of agile methods? Because they are realizing that they need to orient themselves more quickly on the market. The wind from the entertainment and communication manufacturers is now blowing quite briskly, the wheel is turning much faster than the automotive wheel. The integration cycles are shorter, although the cycles in the automotive sector have also become much shorter. OEMs have the challenge of being tied to the context of safety-relevant topics and having to go through time-consuming approval procedures, some of which (supposedly) require a waterfall-like approach. And then there is the question of how to get the driver off the hook.

I'm also writing a book about speaking in dialog, but there's no date for it yet. This is the result of my previous work. I've never been a fan of frontal presentations in sales. There is literature on the subject, some of it good. But I haven't found anything on the subject of "dialog". Unfortunately, it's often about convincing an "opponent", i.e. "us against the others". But I can't argue against someone, I have to do it for someone. And I haven't found that idea yet.

I've been helping to organize events myself for a long time, especially barcamps recently. And the barcamp format seems to focus precisely on this idea of dialog.

Looking back, I can see that some events - especially internal ones - were pretty close. I was at one for the first time in November PM Camp in Dornbirnwhich I thought was excellent. The classic conferences will of course still have their place. On the one hand, when it comes to publications, but many conferences also leave enough space for individual exchange. Of course, this often depends on the organizer and the session chair.

These are all exciting topics that have been with me for the last few years. I'm excited to see what's in store for me.

Picture: Joachim Schlosser