Siemens has expanded its solution to cover embedded software. It has come out of Siemens’ Capital set of solutions. Capital is a suite that addresses the development of electrical/electronic systems. So why would that solution come out of there? We’re going to talk about that here in a second. There’s a lot of capabilities there. When you look at Siemens overall, you have Polarion as far as an application lifecycle management solution, and that can be plugged into Teamcenter, the product lifecycle management solution too.

We’re going to talk about virtual verification. We’ve discussed model-in-the-loop and software-in-the-loop in the past. Today, we are going to focus on the capabilities of VSTAR, which is a solution that’s part of the Capital suite.

What is Capital VSTAR?

Now the best way to explain what Capital VSTAR does and the rest of the applicable solutions that fit in the space from Siemens is to walk through an example. In this case, we’re going to be talking about a car. We’re developing one of those automatic braking systems that senses the thing in front of it and applies the brakes. It has software aspects to it. It has a board system. There’s a network involved and there’s actuated components in terms of the braking system itself.

Now there’s a bunch of challenges on this front. First and foremost, I mean the traditional prime concern is how do you know that the software will actually run as intended on the processor? Usually, with these types of systems, you have to have a customized C or a programmed FPGA because you got to process data extremely fast.

But how do you know it’s going to run on that? But not only that but how do you make sure that it’s going to be compatible and interoperable on the entire board system? Another concern beyond that is how do you make sure that it works with all the other electronic endpoints within the E/E system?  These are some of the concerns that you need to address along the way.

The Traditional Way to Check Software Logic: Model-in-the-Loop

Let’s talk about how a lot of companies are doing that right now. The traditional way that you make sure your software logic is actually working as intended is to use this approach called model-in-the-loop. So basically, you build a model of your software logic. This isn’t code. This isn’t binary. It’s actually just a model like a flow diagram. Then you build a model of your physical system. In this case, it’s going to be the brake system, and you connect the two. You connect the two through this functional mock-up interface. This is a standard interface between systems models.

The way that Siemens supports this process today is by using AiM SIM to model up the physical aspects of the mechanical or actuated system. So AiM SIM is part of SIM Center. It was an acquisition from many years ago, but it’s really good at 1D analysis. You can use it as part of prototyping and testing. Actually, you can use it all the way over into kind of IoT and digital twin stuff if you want to do that, but it has some really powerful simulation capabilities. You can connect your model of your software logic to the physical representation, and that way you can verify and makes sure that your software logic is correct to start with. Then, you move on to the next phase.

Using Software-in-the-Loop

At this stage, we need to make sure that the software runs on the processor and gives us the same logic. I want to verify that. This is where you apply software-in-the-loop. You compile the software into binary and then you run it on a virtualized processor. Now, these ICs can take a long time to develop. You don’t want to be sitting around waiting for six, twelve, maybe more months than that waiting on a prototype chip. You want to verify it so you can progress in development instead of sitting around and waiting.

So this is where a software application running on your local desktop will emulate the behavior of that processor so you can verify that the software logic, even though it’s now being compiled, still works and it still gives you the behavior that you want. This is the first spot where Capital VSTAR comes into play. It can emulate that processor, whether it’s an off-the-shelf one, an FPG, or maybe a custom one. You can run the binary on that virtualized processor and test it in the same coupled manner that we did with model-in-the-loop.

So this is an interesting point. There’s a lot of companies that talk about X-in-the-loop, model-in-the-loop, software-in-the-loop, hardware-in-the-loop, and all that stuff. But there’s very few companies that can offer this virtualization capability of the processor and connecting it to a plant simulation that represents the mechanical or actuated system, in this case, the braking system. So this is one point of differentiation, especially that they can virtualize the processor and be running the plant model both within Siemens type of solutions.

Using Virtualized Boards

Now verifying that the software runs on the processor seamlessly and it gets the behavior you want, that’s important, but that’s not the only thing you really need to do. You got to also make sure that it runs on the board. There’s all sorts of other interactions that the software will have with the board. It is processing signals or messages from all over the rest of the car, whether that’s from sensors or other electronic endpoints through the network. So you got to be able to do that too. This is where you want to be able to run the binary on a virtualized board and not just the processor. And this is where Capital VSTAR comes into play too.

Now, this is certainly a space where I haven’t heard anyone else being able to do this – to do it at the board level. And actually, it is pretty important. You don’t want to have to wait for a prototype chip, but also you don’t want to have to wait for the prototype board. That’s a delay in the development process a lot of people have been living with. Kind of the next step is, it’s interesting, you go from model-in-the-loop with the software model to processor-in-the-loop or software-in-the-loop where the binary is running on a virtualized processor. And a lot of people go to hardware-in-the-loop, which is where you have a prototype board.

But there is now this intermediate step that we just talked about, where you have a virtualized board and you verify that the software runs on that and you don’t have to wait. You can address design issues and other integration issues through this effort instead. And that’s great. Again, I haven’t seen anyone else providing this capability. But actually, that’s not the end game. There’s another step here.

Virtual Verification of Communication Between Electronic Endpoints

Now the issue here is that it’s not just about software running on one electronic endpoint and controlling some physical assets effect of the solution. This embedded system doesn’t operate independently on its own. You actually see a lot of companies now distribute functions. They interact with one another across multiple electronic endpoints. So there’s an interaction here that has kind of been missing so far. And again, you don’t want to wait until prototyping and testing to figure out if it all works together. That’s late in development and there’s all sorts of issues with that.

So the solution here from Siemens is having a virtualized board system with the software running on it, coupled with the simulation of whatever physical system that it controls. And again, this works in the same way that we just walked through a second ago. But here’s the key. Again, these don’t run in isolation. You actually want these to be interconnected. This is where Capital VSTAR will virtually verify the communication between these electronic endpoints. So it’s not just these coupled simulations talking to one another in their own silos. Capital VSTAR will support, simulate, and verify virtually how these different electronic endpoints communicate to one another.

So this is where you see a real differentiator. It’s like kind of stacking on top of one another now. Virtualizing the circuit board was one level, but now there’s another level where it’s virtually verifying everything about your network and then communication that kind of goes back and forth. So is the timing right? Is everything receiving things at the right time? What’s the bandwidth of the network look like? Is it being overloaded, all sorts of issues like that?

So if you step back a little bit, there are now two other phases in the X-in-the-loop kind of structure. We had model-in-the-loop, which was just about the software model logic. Then, we have software-in-the-loop, which was all about binary running on the process. But now we have the binary running on the virtualized board, and now the whole E/E system running in a virtualized fashion with all the electronic endpoints running with their own virtualized aspects, and then also simulating how the network is going to perform.

And all of that goes before hardware-in-the-loop, which is where you get prototypes of the board. Maybe you build out the network, the harness itself as a first iteration on the prototype to make sure that it all works. So this is virtual work that happens now, that has been added in and it adds a ton of value because you can identify issues and resolve them long before you spend money on building up a prototype. And you really want that to go through right the first time. So that’s it. That’s how Siemens offers solutions for embedded software now, and kind of what is entailed for one aspect of it for virtual verification.