Software Architectures and Virtual Integration in Model-Based Design
See how Simulink is rapidly evolving to go from software architecture conceptualization to deep component design and back up to software integration and testing, enabling higher quality and reliability of embedded software.
Published: 7 Aug 2023
Hello, everyone. So we had a lot of interesting talks this morning. And continuing with that theme, we all know, as-- I think as Hans said very well this morning, this whole idea of software-defined vehicle has been a transformation that's been happening for the last two decades.
And during that transformation, as you summarized very well, the E/E architectures that you are all evolving has also been transforming over that period of time. Now, this is all-- and I'm sort of preaching to the choir here. So what's next?
So in this journey that you have been undertaking, we, from the Simulink product-- Simulink platform perspective, have been your partners, I hope. And we are asking, what's next for us? What's our evolution as you are making this transformation?
So today, in the morning, Andy laid out a much more sweeping vision of all the different investments that MathWorks is making in this direction. So next question becomes, how do we align the software development practices of these transformative E/E architectures that you are all adopting? How do you align that with what we have classically called model-based design?
And for that, I'm going to focus on basically the more focused investments we're making in the modeling space. And there are two basic themes I want to pick on today. So the first theme is, how do we go from models, which you have all been building in Simulink for, basically, software components in the past-- how do you go from that to architectures?
And for that, today, I'm going to take what-- the investments we've already making in the architecture space with System Composer and ask, how can we add the capabilities that are specific to software, like service orientation or principles and the software frameworks that you all use? How do you bring that all into the architecture modeling space?
And the second theme is taking what we have done classically with our-- you know the familiar Play button in Simulink for simulation and talk more about virtual integration. Once again, I want to touch upon themes that are basically, how do you bring code-centric and model-centric design into one framework? How do you do automatic model assembly, where you can assemble virtual integrations quickly? And finally, how do you do simulation in a larger context, like with the CI systems that you are all trying to go towards?
So I'm going to pick these two themes today and try to give you a mountaintop's view of all the various investments we are making in these spaces. So first, let's talk about models to architectures. Now, you can think of software architectures as abstractions that are useful so that you can provide good implementations. I mean, obviously, there's a means to a real end, which is you want your software implementations.
Now, you can think of these abstractions as being on the sliding skill of rigor. You can start with something simple like class diagrams or representations that you even draw on sketches. And then as you move forward, you can conform more and more to a more rigorous methodology.
And as Remy showed in his talk, you can actually go all the way towards proper component frameworks with well-defined ideals that are then both suitable for modeling and simulation as well as for code generation. So really, we want to be able to see how our tools can span this process from concept all the way to implementation as seamlessly as we can.
And one other thing to note is if you look at the component-- if you look at all the frameworks that you're using, they are all slightly more higher on the rigor scale. They are usually component-port-connector paradigms that are very familiar to us as a modeling tool. And so basically, we feel like very, very strongly that we can actually get to the rigorous parts of where you want to be.
And what we have done is introduced System Composer as an architectural modeling capability on Simulink to be able to slide on that scale of rigor from basically simple conceptual design all the way to implementation. And today, my job here is to try to show you how that may be the case, especially for software.
So I'm going to give you a really fast tour of System Composer for those of you who are unfamiliar with it, again, just touching upon the common elements of architectural modeling. The first part of this is sort of agnostic to whether it's system architecture or software architecture, because architectural abstractions are very similar in both domains. Later on, I'll talk about software specialization.
So first, let me start with the basic principles. First thing, we can express structure, which is using the familiar component-port-connector paradigm. Not a surprise here. And what we're trying to do is allow this to happen very quickly and intuitively.
The next thing, as you elaborate this conceptual design, we'd like you to establish your interfaces and start to add incremental levels of detail to your design. That's again quite familiar. And then as you go along, we want to bring all the architecture metadata that you have into the architectural framework. So we've added this idea of profiles and stereotypes.
What we have heard over and over again with the customers that we're working with is architectural data tends to be wide, disparate, and specific. So how do you bring that all in a simple and easy way into a common framework? So we've been inspired by some of the standards out there like SysML with their profile infrastructure. And you get something similar here.
And from that, we also add the ability to add requirements-- requirements tracing through our Requirements Toolbox. That is, again, quick and easy and intuitive. We know a lot of requirements engineering is happening as you're doing early architecture design. So that needs to be in canvas.
And finally, we also have this capability which is actually very popular with a lot of System Composer customers. Architectures start tending to look like this, right? And this is actually a simple one. And usually, it becomes a hair ball. So what you really want is to be able to take something like that and quickly arrive at something like this, which facilitates the-- first of all, the design process, the review processes that you all follow for software and for system. So you really want things like this to be easily available and accessible. And so that's something we have put a lot of effort into.
And then once you have that basic structural diagram, you can start adding behaviors. So once again, you can take conceptual elements and associate them with sequence diagrams here, as we are showing. And one of the exciting things is since we are modeling and simulation capability, you can take these sequence diagrams all the way to tests. So you can actually run the sequence diagrams, run your models, and verify that these sequence diagrams are being met by your design. So that's something exciting that we offer.
And last but not least, you obviously can link down to implementation models and carry on Simulink model-based design from these architectural models. And I think Andy elaborated upon that point this morning. And so yeah, this is just showing all the linked designs inside.
Now, what I want to focus on is-- so what? So what, how, what software? One of the things is if you look at the basic framework of architectural modeling and all the associated ecosystem around it, in this slide, I've shown you all the things you can do for software modeling.
Now, if you replace the word "software" with "system" here, pretty much, all of this holds good. So the real challenge is, what are the aspects of this architectural framework that are software specific? So to do that, I'm going to do a really quick lightning demo of things you can do.
So here's a simple canvas. We're starting to model a four-component software architecture. You can quickly start sketching. This is showing how we're adding sketching and adding stereotypes. Stereotyping gives you different component types. So the colors appeared right off the bat.
We're also starting to associate service interfaces like the ones Remy showed this morning. So those service interfaces were imported. And those are the client-server interfaces, for those of you who maybe can't see it in the back.
And then what you can do is once you have those client-server interfaces, you can take individual components, associate Simulink behaviors. That's what's happening now. We also provide default behaviors for those implementations. So once you go into a component and ask for a default event implementation, it gives you one.
And quickly, you can simulate, start seeing the events that are crossing across from each component to the other. You can then dive into the component and actually generate Adaptive AUTOSAR code by a quick click of the button. And it gives you both ARXML extract for Adaptive AUTOSAR as well as it gives you the code for it.
Now, I know all of this happened in maybe a minute and 30 seconds, intentionally fast. But the idea here is to show you that although this is a small and simple example, what we are trying to do is complete your workflow from starting point, from concept, all the way to endpoint, which is implementation. And some of what I think Remy showed in his talk, again, this morning is inspirational because we want to make what he was showing intuitive and easy as part of what we are doing. So lots happening here.
And I think I want to start to summarize what you all saw in terms of what I showed you. First, the thing we showed is here. We can describe SOA with System Composer with client-server ports. You can implement components using Simulink. And you can generate code using Embedded Coder. But that's not all.
I know this is a crowded slide. I'm not expecting you to read this. But we have completed those SOA workflows in many different tentacles. Quality of service is one thing that comes up. How do you model for these client-server ports. So a lot of work happening there.
And similarly, we can also think-- add sequence diagrams, or we can add test harnesses for your-- so you can do unit testing of those service-oriented components. All of that is sort of coevolving with our basic functionality that I showed for architecture modeling.
And then once we are done, we can also do other things that are familiar. Again, UML diagrams came up this morning. Class diagrams are easy and intuitive ways to look at software abstractions. So we have started adding class diagrams. Editability of class diagrams is coming soon. It's a highly requested capability. You can go and start to edit your server interfaces directly in the class diagram and see it happening, see it coevolving with your model. So again, that's something we are-- we've started to introduce and go ahead with.
And then you can do internal behavior. So you can implement using the traditional functions notation that is Classic AUTOSAR, like the runnables and AUTOSAR situations. So you can still do all of that in canvas. You can then schedule them. So you can add the scheduling constructs and make sure that your tests are able to figure out whether these components are scheduled correctly.
We can also then do more detailed implementations. I know state charts are very popular software modal logic implementation. So clearly, our road map into Stateflow or our integration into Stateflow allows you to do that intuitively on our canvas as well.
And then, of course, the deep solutions and workflows we can complete-- we've introduced-- AUTOSAR is highly popular. So we do Classic AUTOSAR support. And we have Adaptive-- growing Adaptive support. And then we also have generic software architecture, especially for embedded Linux. And that is something that's coevolving as well. You're not tied to only Adaptive AUTOSAR.
And ideally, we'd like to also have customizable IDLs, like Remy's talk this morning, and be able to integrate your own version of middlewares with what we are doing. And finally, we have other frameworks like DDS and FACE and all of that under consideration as well.
So lots happening in just the model-to-architecture domain. And again, it was a whirlwind tour. What I'm hoping here is to trigger those thoughts in your head so you can figure out how you can pose problems for us to solve in our tools.
So next, I want to switch to the second topic, towards virtual integration and simulation. Now, here, obviously, the conversation is around shift left. It's come up several times this morning. Then the question is, how far left do you want to go?
And so our question to you is, how far can you bring virtual simulations in your workflows where you are deriving value for your ECU simulations? And one of the things that keeps coming up-- this is from the PROSTEP folks. And I know several of us-- several of you have posed questions to us, asking, where is Simulink in this road map?
We think this is a good way of thinking of ECU levels of fidelity. But I think it underserves how you think about model-based workflows here. So in our perspective, Simulink is great at the bottom left aspect of this because what we are uniquely positioned to do is to bring model-oriented and code-oriented workflows integrally into one canvas where you can perform this virtual integration tasks. So we think that's where our sweet spot lies.
So with that, let's see what kinds of investments are we making to achieve that? Now, Andy touched on a lot of those investments this morning. And it's a really sweeping space. But I want to cherry-pick some specific things that are very relevant to virtual integration. First is you need to integrate parts. So how do you create these parts quickly and easily?
Then how do you do assembly? One of the things that's coming up more and more is this notion that there are so many variants of your design, topologically as well. So how do you assemble models that are quick and easy to perform virtual integration on? And then last but not least, how do you go to performant simulation?
So let me cherry-pick a few things that we are doing in terms of investments here. Model reference has been our workhorse componentization strategy for maybe two decades, same as the software-defined vehicles trend, I guess. And one of the capabilities that we have in there is what is called protected models, which was a way to create models with IP protection.
We are slowly evolving this to really be a solution that is a containerized ready-to-run model. What does this mean? So what you would do is basically, if you are a creator of a model, you would package these models with specific features that you want. For example, do you want IP protection or not? Do you want local solver, which is a very important capability, especially as you're packaging planned components?
And then you can create these packages that you can then give to somebody else, who when they perform integration, basically, it's already ready to run. So you're not paying any cost for compilation. Its startup cost is instantaneous, so to speak.
So our idea here is you take these models, construct these ready-to-run parts, put them on a shelf, an asset library, and whenever you have any need, you pull those models from the asset library and reuse them. So that's the vision here. And we're really far along. In 2024, we hope to be achieving some of the milestones in this direction.
The second aspect for ready-to-run components, we are making heavy investments in FMUs. We have actually evolved our support to FMU 3.0. That's coming in 23b and 24a and so on. And we believe that this is a strong way to bring other third-party implementations that you have into Simulink as an integration platform.
And it also, for some of you, offers a way to create packaged ready-to-run parts of our models. And we understand that. So there is this push and pull with FMUs. And so we are actively investing in it. And we hope to be best in class in terms of FMU integration as well.
Last but not least, the concept of SIL keeps coming up. You have code-based implementation. And you have code-centric development. At a recent MAB survey, it was something like 75% of you had a hybrid of model- and code-based workflows. So where are we headed there?
The idea we want to explore, basically, is you would take all the code that you're doing and build something that we can connect to. We understand that code building and the process of creating these complex code architectures is highly proprietary, sometimes highly custom. So what we would hope to do is much more-- if we can give you a mechanism or an SDK, where you can build these containers, where you can have connectors which are service-oriented again.
And some of the examples-- you actually saw on Remy's talk, you could use a gRPC, which is a popular format for service-oriented abstractions. And bring that into the simulation world. So you can build these code components and easily integrate them all into the canvas, just like you would do with models.
Now, here's the power of doing it that way. You can automatically start getting the power of distributed simulations because these containers, you can put them on different machines, on different cores. And so performant SIL-based simulation is within our reach once we take this strategy into account. So this is, again, an exciting direction for us.
With that, we have the parts. We have code parts. We have parts from other tools. And we have parts which are models. How do you bring this all together? So in this direction, we are trying to look at autoassembly.
One of the ideas here is you have an asset library. You pick certain assets. You topologically create new models from them. So this is a framework we are really working on because a lot of you have tooling that does this today, and we understand that. So we want to make it much easier to do this natively.
The question, of course, becomes, how do you go to model assembly from parts? How do you pick these parts? And one of the interesting ideas we're exploring here is this idea of a feature-driven approach.
And I think Andy alluded to it in his talk. We have what is called a Virtual Vehicle Composer in our Simulink automotive products. And what we're doing there is pick the features of the vehicle that you are interested in assembling. We automatically pick the parts and create models for you from it.
So that's the first natural embodiment within our own tools. We would like to put that in your hands so you can build your own feature-driven model assembly tools. So that's something we're excited, and we think we are on a really good trajectory towards.
And then finally, last but not least, I cannot do this justice, but that's why it's just a one slide. We think we can take all of this and bring it all into this Simulink platform, which has a lot of capabilities for distributed simulations and simulation sweeps.
So really, we can take the components, assemble them, put them together in a model, and then we can hit the Play button, have all kinds of testing tasks. You can get the million simulations that Andy was alluding to in his talk, all through the core simulation capabilities that the Simulink platform already offers. So that gives us a sort of a leg up from simulation to now virtual integration.
I think I can start wrapping things up here. It's sort of a whirlwind tour, like I said, of all the modeling and simulation investments. But I think the core idea here, just to summarize, is we are creating this concept of software architecture in System Composer on top of the Simulink platform. This allows you to have the classical design flow of going from requirements all the way to implementation or design models.
And of course, on this, we want to overlay all your software-related workflows for service orientation and for frameworks and achieve the virtual integration that you expect from the platform. So I think this is really the sweeping vision that we are setting for ourselves.
So how are we taking this journey, you might ask? And this is where you come in. And here's an illustration of some of the most recent things. And of course, I had-- this was even before I knew Remy was talking. He's referenced here already.
And here are examples of some of you who are working with service-oriented architectures. And we also have, similarly, lots of industry examples of where we're working for virtual integration. Really, so you are the ones who are keeping us true to this journey. And if I may use a pun, you are the ones who are helping us autonomously drive this trajectory.
Now, I want to conclude a few MABs ago, I put this slide up, which is a classical play on plan controller design. And somebody made a joke about the z to the minus 1 and why that even existed. But that's for another day. But what I want to say is maybe it's time to refresh that picture. So this is my new attempt at it. And we're going to go with client-server ports.
But all kidding aside, what I really want to emphasize is the teams that I work with in the Simulink core are extremely motivated from the challenge problems that you offer us to be able to drive in this new path. So as the talks this morning illustrated, you are in the process of a transformation. And your direction will really help us set us on this path. So please come and approach us. Provide these challenge problems so we can develop the tools for the next decade for you. Thank you.
[APPLAUSE]