The future of modeling: Interview with Andreas Willert (Part 1)
This is the first part of an interview with Andreas Willert, Managing Director of Willert GmbH, which specializes in software engineering in the field of embedded systems. In addition to his business activities, he is a book author and a frequent speaker at conferences and other events.
I spoke with Andreas on October 10, 2019.
Note: Andreas Willert and his co-authors hold the seminar Model-Driven Embedded Software Engineering on December 2 at the ESE Congress 2019.
What is the status of modeling in system development?
Interesting that you are asking about system modeling and not software modeling. In the field of MBSE (Model Based Systems Engineering) we are currently experiencing a huge hype. In SE, the realization is becoming more and more widespread that complex systems can no longer be described textually on the basis of can no longer be described textually on the basis of requirements alone, but that models are needed.
There are currently many prominent projects, such as FAME at Audi or SEED (Systems Engineering Enhancement@DAIMLER) at Daimler. Here is the statement from Daimler:
At Daimler, we digitize every component before it is installed in order to detect problems at an early stage, but not in software and systems engineering. That has to change.
These are precisely the bottlenecks that many of our customers have today. Today, mechanical components are digitized and first assembled digitally before a component is released for production. This is not done with software and systems. The SEED program is about making the entire system simulatable before it goes into the individual engineering disciplines. And you can only do that with models.
What is the main driver for these initiatives?
Complexity! Someone loads the trunk, closes it, and the system keeps opening it because something is bothering it. The developers sit for months looking for the problem through the various dependencies of the systems.
As the complexity of the system increases, so does the number of dependencies and the risk that these are not fully taken into account when a change is made. Where unconsidered dependencies (so-called hidden links) occur, emergence occurs. And dysfunction can then arise from these undefined reaction patterns. And the more complex the systems become, the higher the probability of hidden links, and the higher the probability of emergence and dysfunction. A real-life practical example: someone loads the trunk, closes it and the car system keeps opening it because something is bothering it. The developers sit for months looking for the cause through the dependencies of the systems across the engineering disciplines.
One sure way to counter this would be to reduce complexity directly. However, this is generally not a solution, as it would mean restricting functions that make the product competitive in the first place. More realistic options are to make complexity manageable, for example by increasing abstraction. I then have a better understanding of the interrelationships.
It is almost always about preventing hidden links or reducing their number. This can be achieved with abstractions, contract-based design or traceability.
Modeling takes effect at various points. For example Contract- Based Design can be implemented much more easily in UML on the basis of ports and interfaces than, for example, with C. Models are effective at the contract-based design level, the abstraction level and the traceability level. To talk briefly about software, not systems: How do you make a unique link to a line of code? There is no metastructure, no unique IDs (UUIDs) in the code or in the editor. However, these do exist in the model - assuming the appropriate tool support. This can then be used to address the problem of "hidden links".
But in programming, isn't the signature of a class and its method something comparable to a UUID?
Show me a tool that can put a unique link on it. Modeling shows a way here, because UML gives me a UUID that I can use for link relationships and, as a result, traceability. This gives us traceability from the requirement to the model, and via code generation to the code. And with suitable tools, this also extends to verification.
Back to the state of modeling: in some areas, it has become established. Half of our customers, for example, use Matlab and Simulink one. There, neither modeling, code generation nor simulation are questioned, quite the contrary
The interesting thing is that modeling has been very successful in some areas and not in others. and not in some. The interesting question is: What makes the difference? I would like to take another look at the different areas of engineering. In systems engineering there is currently a huge boom in modeling. In software engineering, I see three areas: I see the static architecture architecture, i.e. classes, objects, methods, etc. This is where rudimentary modeling, for example with Enterprise Architect, because the tool the tool costs almost nothing. This is often used to generate generated from this. In behavioral modeling such as controllers and state machines, Matlab has become very popular. There, too code generation is used throughout and is no longer questioned. questioned. And there is the event-based architecture, where UML tends to be UML tends to be used again, but has not really been able to assert itself. really become established.
Interestingly, UML has not really been consistently implemented in software development to this day.
Interestingly, UML has not really been consistently accepted in software development to this day, especially not in consistent application, e.g. as in Matlab / Simulink. And code generation is often rejected there, in contrast to Matlab.
This is not a new phenomenon, it's already 15 years old. Back then, there were also reservations about Matlab but there are now two code generators, 'TargetLink' from dSpace and 'EmbeddedCoder' from Matlab itself. There is a consensus that modeling without code generation code generation brings few advantages.
I also have an explanation for this - I don't know if it's true, but that's my interpretation. Those who work with Matlab typically have little programming experience. They are mechanical and electrical engineers who develop controllers. For them, coding a controller is a problem. They are happy that they can click together and simulate the controller in their domain language (Matlab). If everything fits, they press a button and the code is generated. From today's software engineering perspective, the generated code is far removed from modern principles. An experienced Java or C++ programmer today would probably beat his hands over his head. Code generation from UML based on Rhapsody, for example, is much more elegant and object-oriented. Interestingly, this is accepted with Matlab, but criticized with Rhapsody.
Why? I suspect because many Matlab users are not necessarily experienced programmers and are unable to assess the generated code from a technical quality perspective.
Now comes the UML and is aimed at the software developer who has been programming C code for 15 years. They can program, but not UML. You you take him to a level where he does not yet have the understanding at model level and model level and has to go through a trough where he is struggling with UML. struggling with UML. And then there's a code generator, that generates code that he doesn't understand at first. It is not necessarily worse, but different, and the programmer has the the feeling that he is losing all control. And he resists against it. At least that's my explanation as to why code generation has prevailed in Matlab code generation has prevailed in Matlab, but not in the application of UML. The target groups of users are different.
In order to benefit from modeling, a learning curve must first be overcome, which many do not dare to do or are not given the time to do so by management in their day-to-day work.
Five years later, customers who have passed this low point say: "We no longer know how we can engineer without models, simulation and code generation."
Does this perhaps have something to do with the fact that a Simulink model is often domain-specific, e.g. a controller, while the UML model is generic?
I don't think so. It is more of a problem that UML was not really specified consistently (from an engineering perspective) in the first approach around 15 years ago. There are two things in particular in UML: It did not immediately have a kind of "action language", which means that we are unable to work completely in the model. At the latest, if you want to query a C variable, there is no UML notation element for it. You sometimes have to go down to the C or C++ level, i.e. the action language. A gap has been left there, but this has always been the case. Even in C there is the option of embedding assembler in-line. This is nothing new or dramatic, but it has prevented developers from modeling because they still had to program parts. Actually an excuse, but I often hear it as an argument. Incidentally, this gap is currently being closed in the OMG UML working group 'Precise Semantic'.
What is much more serious is that when designing the UML, the three amigos didn't even have code generation on their radar. That still amazes me today. Especially since up to this point, all established modeling tools for software supported code generation. Rose RT (Object Time), StateMate, STL-Suite (SDT) or Rhapsody).
When UML was created, all successful software modeling tools could generate code. In my opinion, modeling was much more advanced back then than it is today.
We still have customers who use the old tools today. ObjectTime or SDT and are very satisfied. They have been modeling with them for twenty years. They don't switch to UML solutions because they are more consistent with these old environments, right through to simulation and everything in between. And this is despite the fact that the tools themselves are now quite outdated.
Modeling in Software modeling has worked before, from the late 90s to the mid-2000s. And in my opinion, the UML, by moving in the direction of "picture-painting" and documentation, UML has destroyed this whole movement and today we are more backward than we were 15 years ago. than we were 15 years ago. Although the basic idea of having a standardized standardized notation was great. The way it was implemented was destructive. been destructive. The three amigos did engineering absolutely no favors. done engineering any favors.
Is the UML perhaps also too complicated?
I don't think so. There are of course several reasons, but I see the problem in the fact that the three amigos have driven modeling towards picture painting and not towards serious engineering with simulation capability of the models and code generation.
The graphic aspect may even have created a fallacy: People think, "It's quite simple, we'll draw little pictures." And people often confuse "detailed" with "precise". And many people say: "It can't be simulated", and think that it would have to be more detailed, that every C variable would have to be defined and modeled before I can simulate. But that's not true. To be able to simulate it, it has to be precise at a certain level.
In UML modeling, "detailed" is often confused with "precise".
One example: If I want to test my aerodynamics in the wind tunnel, I need to create a model of my car or airplane that is very precise in terms of its aerodynamic properties. However, it doesn't have to be detailed, i.e. include the engine and gearbox, for example. This is often confused, especially by programmers. They often have no idea how to abstract upwards at all because they have never done it in their lives.
In the past, a lot of development work was done from the bottom up rather than from the top down. You build a small fragment here, put the CAN bus into operation first, the sensor there, and so on. With UML, or model-driven, you take exactly the opposite approach. This is unimaginable for most people, and they have never done it in their lives.
This is a handicap, not working in detail instead of precisely, perhaps defining the interfaces with ports and concentrating on architectural aspects such as contract-based design. It is not important in an early design phase whether an integer or float is used here. It is much more important if I abstract top-down, is "kilometers per hour" put together with "miles per hour" here, or is a valid sensor value also delivered when the ignition is off? We first need to be consistent on a logical level, not in detail, but in terms of precision. This must be verified before I implement it in detail. The curve where costs explode over time when errors occur or need to be rectified should be generally known. Taking measures to reduce the risk in the early design phases is the basis for saving costs and time. This is what is meant by front loading and it is indispensable as complexity increases.
