For Mehran Mestchian from MathWorks, who developed Stateflow, is certain that the basic principles of engineering design will remain the same when AI becomes part of the process. Nevertheless, the Senior Director of Engineering is convinced that engineers must be prepared for fundamental changes: Instead of implementing the design themselves, the designer will create the loop for creating the design, which will then be executed by the AI. Accordingly, some developer skills will no longer be needed to the extent previously required, while other skills that were previously only used occasionally will come to the fore.
AEEmobility: During your presentation at the MathWorks AUTOMOTIVE CONFERENCE 2024 Europe on the use of AI in engineering design, you mentioned that the principles of engineering do not change through its use. What do you mean by that?
Mehran Mestchian: For me, design is the deliberate shaping of things to give them a preferred form, and technology is the application of science and maths to solve problems. In technical design, we bring these two aspects together.
If we now add AI, only the how – i.e. how we implement the design and the problem solution – changes, but not the why.
I keep presenting this definition to various engineering groups to hear their thoughts on it. There are very big differences that are worth thinking about. The answer to the question of what constitutes engineering design is also a personal journey.
Regardless of this, technical design is a goal-oriented process that puts people at the centre.
The use of the abductive decision-making method is of central importance here. In other words, the developer must draw conclusions even with incomplete information. This type of logical thinking is indispensable for the act of engineering, in which thousands or tens of thousands of decisions have to be made. This decision-making involves iterations to solve problems.
The definition of the preferred form or the target orientation cannot come from the AI. The AI can help to refine the goals and automate the loops. AI increases the ability of these loops to do their job, perhaps giving the developer more time to think about the design goals.
But the use of AI does not change the fundamental design principles.
Mehran Mestchian is Senior Director of Engineering
of MathWorks and is, among other things, the developer of the Stateflow tool.
So you are convinced that a human actor will always be needed?
How should the AI decide what the goal of the design task is? Whether you use the optimisation toolbox in MATLAB or an AI or a generic algorithm, it is still the human designer who determines what their preferred solution is by defining the experiment or development loop.
The development loop is the actual result of the designer’s thought process. It is of course possible that the loop also includes decision-making. Of course, we want to make life easy for ourselves and automate and delegate decisions. There is nothing wrong with that!
Even very complex problems can be solved in this way: Divide the problem into thousands of loops if necessary, using every available technique such as optimisation algorithms and other mathematical methods including AI, and automate as much as possible.
So instead of creating the design themselves, the developer creates the loop for creating the design. To do this, the developer must define the key points of the desired result, but no longer needs to know all the details. He then has to decide whether the result is good enough or not after passing through the loop.
This basically corresponds to the systematic approaches that we have always used to break down complex, barely manageable problems into sub-problems that we can then solve.
Of course, each of these sub-problems has constraints or boundary conditions that must be met. Usually, technically speaking, this results in an impedance mismatch: the optimal solution of one loop is not compatible with an optimal solution of another loop.
There is still the problem of conflicting objectives with the divide-and-conquer approach, as you see it when using AI suggest?
I expect that with the progress we are making, we will be able to use AI, and generative AI in particular, to automate this linking of the design loops to a certain extent. This would mean that the developer could focus much more on the why and the development goals.
The overview of AI-supported tools in the MathWorks portfolio shows: Their number is increasing rapidly. © The MathWorks, Inc.
To what extent do the skills of the developer have to change as soon as AIs become part of the design process?
The skills of engineers must change disruptively with the use of AI in engineering design, but in a different way than most people expect. I have already practised this with some of my teams. It became exhausting. As a developer, I can no longer sit back and say, „Look, boss, my code is very efficient, you can increase my salary“, or „I’ve spent so much time optimising this“. In future, it will be much more about dealing with the design goals.
However, the engineers do not need to learn completely new skills for this. They need strengths that they already have as developers but have only used occasionally so far.
During my time as a consultant at Bosch Scintilla, one of my tasks was to develop a charge level indicator for battery-powered 9.6 V drills. I essentially solved the task with a Kalman filter. It was easy to develop. But then I spent six months writing low-level code to get a fixed-point implementation of the Kalman filter.
And once I had done that, it was only the beginning, because there were all these many states for which I had to create lookup tables that mimicked the behaviour of the battery. That still wasn’t the end of the work – I still had to integrate the whole thing into the state of charge estimation microchip, which of course was too small for that, so I had to offload the code to the charger’s processor. To do this, I had to set up a communication network between the state of charge estimator in the battery pack and the charger.
The crucial question: How much of this was the innovative part that made the difference? AI can help us to free up more time for working out the added value.
What would be your advice to engineers who want to adapt to the new way of developing and take their first steps? Where should they start?
We need a sense of achievement. I can’t say where these will emerge first, but typically it happens at the edges of a particular segment of the industry. The success will then speak for itself and will be mutated and imitated in many places. This was already the case with model-based design.
When we at MathWorks became convinced that the use of model-based design in engineering would be worthwhile and that we had the necessary tools with MATLAB, Simulink, Stateflow and the production code generators, many developers still saw model-based design as a costly additional step and rejected it. However, we were able to convince some developers and they took up the topic and hit the bull’s eye.
The first European company to do this was Mercedes-Benz. They used Model-Based Design under the leadership of Armin Müller in the development of ESP. Akira Ohata at Toyota and Ken Butts at Ford championed the new method and celebrated successes with it.
Mind you, they were not yet engineers in management positions at the time. But they hit a home run with their commitment to model-based design!
The ESP programme was a direct hit. It was the first ADAS system. Some people asked themselves how they did it at Mercedes Benz, maybe we should change something here.
Unfortunately, I do not have a more concrete answer to your legitimate question.
But there are engineers who are already using AI today. We will learn from what we have overlooked, what we may have done wrong, and we will adapt accordingly. This is simply part of the incubation period or follows the course of the often-cited innovation adoption curve. I don’t know where we are on this curve at the moment.
The four main cateogies in the context of AI models. © The MathWorks, Inc.
The potential of AI in engineering appears to be high. However, there are concerns in Germany and Europe that we are lagging behind in the use of AI in tools and applications. How do you see this?
Answering this question is not easy. Let me explain. MathWorks has been involved with AI since the beginning of the machine learning era. We introduced the first toolbox for neural networks back in October 1992 under the name Neural Network Toolbox. Now it is called Deep Learning Toolbox.
Why I am struggling with your question as to whether Europe or Germany has already lost touch has to do with my personal perspective as a MathWorks employee.
MATLAB is known as a trustworthy environment for numerical calculations. People have been relying on it since Pentium times.
We are putting a lot of work into generative AI and other things. The key question is: how can we ensure that we don’t dilute the value proposition?
Technology is calibrated for precision. Our industry is all about accuracy, quality, reliability, safety and security.
The precision of the AI answers is therefore crucial. However, LLMs use maths based on stochastic processes and are therefore not particularly precise. In other words, the answers follow a normal distribution. We therefore need numerical guard rails that are verified by simulations.
That’s why I say to some of my teams, if you want to use an AI co-pilot, do it, but make sure you analyse and test the code in Polyspace in terms of software quality using static analysis.
What still needs to be done for AI to find its way into engineering?
Data security must be guaranteed. The attack surface of LLMs for cyber attacks is huge! There are numerous ways to crack an LLM. For example with backdoor attacks.
There are many ways to corrupt data, even if you don’t intend to.
So if you notice that AIs are slow to emerge in the engineering process, it’s because we’re dealing with a technical field. Our work is more difficult. Live with it. Enjoy it. It’s worth it.
Use of AI in model-based design. © The MathWorks, Inc.
How would you describe the job of a future software systems engineer in the automotive industry?
The job advert could read something like this. We are a German automotive company, a leader in the use of AI technology in safe and reliable automotive systems. We are looking forward to an engineer who is familiar with dynamic calibration engineering of AI models in automotive systems. He or she should have in-depth automotive systems knowledge and experience in using data science in this environment.
Did I say C programming? No. C++? No. Python, MATLAB? No. Because I’m assuming that the software platform, the middleware that the company uses, is stable. A single company cannot raise the financial resources to employ thousands of engineers for this. My ad text is therefore based on the assumption that the relevant stack has been developed by other, specialised companies and has presumably been largely standardised.
But what then is the distinguishing feature? The distinguishing feature lies in the way the OEM controls the dynamics, how it shapes the overall car system and how efficiently it can change the design.
All these things that do not require programming, or require a new type of programming, are what Andrej Karpathy called Software 2.0 during his time at Tesla.
Impact of AI on engineering workflows. © The MathWorks, Inc.
However, if you look at modern workflows in model-based calibration engineering, you realise that the basic principles between Software 2.0 and the work of calibration engineers have a lot in common. I think there is a huge amount of institutional knowledge in model-based calibration engineering that can be translated and generalised into Software 2.0! For this reason, I sometimes refer to workflows aimed at EdgeAI as designing and calibrating „fancy lookup tables“.
So the software engineer of the future will continue to work with software, but not in the way we imagine today – it might be similar to what calibration engineers do in principle. That’s my prediction, which we are currently approaching asymptotically.
As software engineers, we need to learn how to systematically divide goals into sub-goals and development loops, and then figure out how to implement these development loops effectively and efficiently.
One last look into the more distant future: How will quantum computing change engineering?
After thinking about quantum computing for a while, I realise that it is another branch of mathematics that enables us to do things that were previously impossible or impractical. Can we already foresee what this will look like in practice in 20 or 30 years‘ time? Probably not. I certainly don’t know when the GPU moment for quantum computing will come or what will trigger it. But I firmly believe that it will come. (jr)
Profile: Mehran Mestchian, Senior Director Design Automation, MathWorks
Mehran Mestchian is an Engineering Director in the Control Design Automation group at MathWorks. He has overall responsibility for modelling languages and verification technologies. Mehran is the original author of Stateflow.
He has contributed to the development of numerous design automation products, including Simulink and the associated MATLAB and Simulink code generation, verification and validation products.
Prior to joining MathWorks in 1993, Mehran worked as a real-time systems engineer and technology consultant in the industrial, automotive, pharmaceutical and communications systems sectors. He earned his Master of Science in Control Systems Engineering from Imperial College and his Bachelor of Science in Electrical Engineering from Queen Mary College, both at the University of London.
