The following content has been provided by the University of Erlangen-Nürnberg.

Thank you very much for the kind introduction.

Yes, I was at Oldenburg for a PhD defense on the Monday, and then on my way back to Brazil I will fly tomorrow.

I asked Wolfgang if I could stop here and present something or talk about research, joint research.

So this presentation is more or less what I have done since my PhD.

So this is, let's say, almost 10 years of work on applying model-driven engineering on real-time embedded systems design.

So the summary of the outline of my presentation is this one.

I will start with a short motivation, then I will give you some details about the methods that I created during my PhD.

It's called a ModRT.

Specifically, I will focus on the specification of the system and also the code generation that includes aspect weaving.

I don't know if those of you are familiar with the concept of aspect-oriented software development.

So I can, of course, give you more details on that.

And then I will show you some of the assessments that we have done of this method and then conclude the talk with some conclusions in the future.

As you, as all of you might know, the design of embedded systems comprises a lot of tasks.

We have different requirements, functional and non-functional requirements.

Some of the requirements, some of the non-functional requirements are as important as the functional requirements.

These requirements are then translated to several specifications or models, let's say state charts, patternets, UML, CISML, and so on.

Besides of that, we have to deal in a project, in embedded system project, we have to deal with hardware and software that usually is not standard.

That means very different hardware, very different software platforms.

And all of these should implement tasks or services that deal with the physical systems.

So we can see that there is an exploding complexity.

So, for instance, if we consider just the electronic systems on a car, we have more than 300,000 lines of code.

That is too much. That's too much to do.

So when we think about the co-design of the hardware and software components, we can face some issues.

For instance, there are two distinct designs. One team develops the hardware and another team develops the software.

These designs cannot be sequential.

That means they both occur at the same time and are performed by distinct teams that much of the time don't talk the same language, don't know the same specification, the same abstractions.

So in order to allow these parallel designs, we have to have well-defined interfaces.

Otherwise, after the design of the individual components, when we integrate everything, we have problems.

Also, one of the things that the people use for this co-design is to try to use high level abstractions for simulations, for creating prototypes.

But the problem is that high level abstractions may have different models of computation that sometimes are not, so to say, compatible.

I mean, it's different. For instance, you think in your system as an object-oriented system, and then you have to translate that to VHDL.

That's a pure component-based system.

We have concepts in one model that are not available in the other model.

So this integration of the information is a challenge.

Of course, we cannot enforce the teams to use the same language or the same abstraction because simply it's not suitable for the team.

For all the tasks that must be done.

So if we consider the requirements, there is still a tricky thing.

For instance, embedded system has non-functional requirements that might be as important or even more important than the functional services.

For instance, we have timing issues.

For instance, we have deadlines.

We have jitter.

We have freshness.

We have response times that must be met for the functions in order for the system to work well.

For instance, in a real-time system, if you lose the deadlines, the system doesn't work.

If it's a hard-to-time system, this means death of people or high costs.

We have non-functional requirements that deal with the distribution of tasks.

As you might know, we have many cores and many processors that we can distribute our tasks.

And these tasks must collaborate.

Otherwise, the system cannot do what it's supposed to do.