Feature-Driven eDrive Development: A Consistent Way to Handle Complexity

[AUDIO LOGO]

My name is Dr. Matthias Brabant. I'm the Lead System Architect at eMoveUs. Today I want to talk about feature-driven iterative development, a consistent way to handle complexity. But before we dive into this topic, I first want to present you who we are. So I want to give you a bit of insights into our company, because we are freshly founded in March '23. So we are a really new company, and we are focusing on developing eDrive products across the complete V-cycle. And especially inverter and e-machine design.

Actually, we are around 55 employees across the complete V-cycle. And we have around 85% graduated engineers and PhD here, and a lot of experience in the iterative development. So yeah, more than 70% of our operational employees have more than 10 years of eMobility experience. And that is what we mainly do. And we see us as a solution provider for electrical drive systems in the development phase, all through the complete V-cycle.

And today I want to talk about our development approach. So first of all, I want to start with a motivation. And afterwards, I will show you the benefits, in our opinion, of combining MBSE and MBD approaches. Afterwards, I want to show a bit of our toolchain in practice. And finally, I want to conclude my presentation.

First of all, as we started from a greenfield, we have the possibility to set up our toolchain as we want it. And first of all, we looked at the market challenges we have. I think the most of these are more or less familiar to the audience. We have the increasing product complexity. We have the market pressure that we must be cost efficient. We have this high project pressure that we need to be fast on the market, and the project timelines are tightened from round to round.

We need to deliver high product quality. Must be process compliant, especially when we have functional safety involved. And on top of that, we need to optimize our systems on system level, which means we can not only focus on software topics or hardware topics, because most of the optimization topics are influencing the complete system. And this is where we ask us the question, how can these challenges be managed efficiently?

Then on top of that, we have our internal demands. One big thing for us was we want to have a single source of truth. So one database or reporting tool where everything comes together. And we wanted our engineers have the time to focus on feature development and not only on process topics, linking requirements, cetera.

To be efficient, we want to also be a high reuse of work products, but not only across projects but also across disciplines. We want to integrate early and continuous testing possibilities in our toolchain to find especially specification or implementation errors as soon as possible, and we want to have an easy traceability. And on top of that, simulation capabilities also across disciplines and early in the development process.

The question that arises to us is, how can a modern development process help us to tackle these demands? And our approach is-- well, first of all, what are the challenges across the V-model? In a classical development cycle, we start on the top left with the system specification going down to describing a system architecture, and then having requirements and architecture as a basis for the several domains to implement these in software, hardware, and so on.

And the problem on that is that we have a very long specification and implementation phase, and start of testing will start in late project phases or when prototypes are available, which means we are here on the right phase late in the project. And this means also that the costs for bugs that are detected in these testing stages-- very expensive when they're found late in the project because this bug fixing loops are very big, and therefore also very expensive. Time consuming. And we asked us the question, how we can deal with that?

And the frequently used approach in software engineering is continuous integration, which means more or less that we shift partially these testing activities to the left in our development cycle. So testing software architecture, for example, with MIL, SIL, and PIL environments, depending on the test you want to do. And we have the possibility to have then an early start of testing activities. And also, if it is automated, we can do a lot of regression tests, and we have a direct feedback to the developer if the software changes, for example, are good or need some rework. And it is done continuously during the development, and not only on the testing and qualification phases.

And the question that arises to us is, how can we shift this approach to the system level? Because this is nice for software engineering, but how can we use this on a system level to minimize specification errors in the system specification, especially for our complex system functionalities that we have? And our approach is to combine model-based systems engineering and model-based design approaches.

And how we do that is depicted here in our picture. Here, it comes all together on a system level. So this process or how our tooling is interacting to each other is outlined here. As I said in the beginning, we have here Siemens Polarion as our single source of truth and the requirement management tools where we do mainly the requirement elicitation, system requirement analysis, and using that also as a project tracking tool and writing test specification, test plans, and also have. A bidirectional traceability to getting test results back to Siemens Polarion, and so on.

And if we now look first at the development process, we can see here on the left that we have here our development process where we focus on our architectural design more or less on a system level. And there we want to also have this bidirectional traceability and seamless integration between the tools. And what we have done is that we use here a synchronization mechanism between Polarion and the Requirement toolbox of MathWorks, where we have a bidirectional traceability of the requirements so that we in the development phase in our architectural design where we use System Composer, we are completely in the MathWorks world and can use directly the link requirements, and everything is consistent.

What we then do is we build up a functional architectural model of our intended functionality, and doing also logical architectural model, which describes then the concrete implementation of our product. And there comes the big advantage of combining MBSE and MBD designs into place. So what we can see here is that we have here-- this logical architectural model is not only a model like drawing a picture, but it's also simulatable. Especially System Composer enables us for doing very detailed behavioral models also on system architecture level, as we can integrate every Simulink or state flow behavior within each architectural component.

And what we then also achieve using this approach is that we can, when we're doing here behavioral models for a new functionality and having some functionality which we then want to bring into the product, we can share this draft implementation also with different departments. We can, for example, sharing this function prototypes with the software department. And they make it production ready, and they have already a draft written in Simulink as a behavioral model which they can use as a basis for the code generation and so on.

On the other hand, we have also integrated a share with our hardware department that models from hardware components, which are usually done in Simscape. We can also use to simulate our logical architecture against our using sensor models and so on. But I will show you that a bit more into detail in the next slide.

On the other hand, if we look at the testing here, we can see also that we have the same possibilities here for the system integration and integration testing where we can use, for example, our architectural model also for virtual system integration tests if we want. And we can also go with these models which we created here. We can also use the same models here on a system for example. And yeah, everything comes then together regarding traceability in Polarion again, where we have the test results here. We have the traceability of the requirements. And so we have within Polarion a direct overview about our project status.

So another view on our combined workflow is now a bit more into detail how it looks in our architecture and how we work with these things together. Here is just an example architecture depicted of a field oriented control. It's not complete depicted here because it would be too much, but I think the idea would be visible here in this diagram.

So we have here, first of all, our functional architecture. So the implementation-independent intended functionality where we allocate functionalities-- for example, here the field oriented control in our functional architecture into a logical architecture here, which consists then of several architectural components, including here, for example, a velocity sensor, a current sensor, and then some software parts. We need to calculate the correct measurement values. We need to have a current control, a PWM module, and in hardware here again, the gate driver.

And what we then have here is that what is our logical architecture depends on the scope of our product. And we have the possibility to use here these hardware modules, which are done in our hardware department to make a closed-loop simulation of this logical architecture, which enables us to test our complete architecture or behavioral test our complete architecture in an early stage in a development process.

And the same model here for our physical plant, we are using also on a Speedgoat here for evaluating then not only our virtual architecture, but then the real product. And on top of that, we have here the share with the software department that we have defined in our company that we have a one to one interface matching between our system components here and our software components here-- that we have the possibility to share these implementation as a draft with the software department. And the software department can share the final implementation with us again that we have here in our logical architecture, the real detailed designs of the software department within.

And what is planned for the future, but not implemented right now, is that we also want to integrate our electromagnetic design department to get more sophisticated EM drive models using reduced order model methods, because we have the EVM data available for our drive systems, and we want to use it in a more sophisticated way. For example, temperature dependencies of the drive and so on. And this in general enables us to simulate very detailed on system level, but with minimized effort.

So now, how it looks like in practice. In practice, it looks more or less like an Simulink simulation, but with System Composer in it. We have first here our plant model. So more or less our physical system which we simulate against our architecture under test. So this is more or less a drive system or a complete powertrain system from the battery down to the load or the vehicle when we want to simulate also a vehicle.

On the left side here, we have our system architecture under test, which is our simulated system architecture, where we have the possibility for each component here where we can integrate using model references in Simulink. We can integrate our system behavioral models which were done by our own, or we can integrate parts of our software architecture. Or if we want a detailed design for specific components, we are very free here to choose what we want to integrate.

Then how do we handle variants? So we handle variants in two different cases. So first of all, in our detailed modular plant model. But the same applies more or less for our architectural model. Therefore, I only want to show here how we handle it in our physical plant model. So it consists, as I said, more or less of the complete powertrain architecture. So we have the battery cable, EMI filter, DC link inverter, AC busbar, cable, EM, and some kind of load that could be a constant velocity drive for typical testbench operation, or also vehicle model if you want to simulate drive cycles with our system.

And on top of this electrical path, we already included here the thermal path to cool down the active components of the drivetrain. And yeah, depending on our simulation use case, due to using a variant management in Simulink, we are able to simulate different kinds of or level of details. So as you can see here for the inverter, we have actually four different variants implemented. And for the EM drive, two different variants. And it is easy to add another variant. And it is also easy to control the variants using the Simulink Variant Manager, because you only need to set up, OK, I want to choose this variant. And every variant control variable is then set by the variant management system.

And here you can see an example of a typical system simulation use case. And what we have done here is evaluating a field oriented control of one of our products. What we can see here, for example in this graphic here, is that we have here a set point in the Q axis of the field oriented control. And then the D axis and the step responses of the system. This is in the DQ coordinate system, but you can also see here the voltage commanded to the drive system in the three phase system and so on.

And this is directly done with our architectural design which includes behavioral model of our control system as a closed-loop system simulation. And this is, I think, the big advantage of this, because we don't need to maintain a separate system simulation because this directly-- our system architecture, which is simulated. So it is consistent regarding the interfaces, and also the components that are involved. And so you have not the work to do to maintain a separate system simulation environment, and also not to ensure that everything is consistent-- so your system simulation environment and your architectural design. So this comes more or less from the shelf.

Then I want to show you a bit how Polarion works, or how our tools interact with Polarion. So we start usually with a product or system requirement specification. Then we have this synchronization from this product specification into Matlab Simulink, which you can see here that these requirements here are imported directly in the Requirement toolbox in MathWorks. And if we have linked all these requirements to our architectural diagrams, we have the possibility to synchronize everything back. And we get also screenshots in Polarion in the system specification that we can directly use this for documentation purposes.

The same applies for the test cases. So we have the test case specification here on the left. We synchronize this test case specification to the test implementation where we write then the tests. For example, the MIL tests and Simulink test with using test harnesses. And afterwards, all the test results are then transferred back to Polarion. This can also be automated. And we have directly an overview in Polarion of our current project status.

So finally, I want to conclude my presentation. So I have showed a way how we can combine the model-based systems engineering world and the model based design world. How we have with that the possibility to do system simulation on architectural level. I showed an approach in our case where we have an high reuse of work products also across engineering domains or different departments.

And I showed a lean and flexible tool chain design and an easy requirement traceability across the V-cycle. And I showed you a short insight about how you can consistently track your project status in one data source. So thank you very much for your attention. And if you have any questions, I'm happy to answer them.

[AUDIO LOGO]