Electric Vehicle Architecture Design and Analysis

First of all, thank you for being here with us today and welcome to this first session of our new webinar series on electric vehicles modeling and simulation from architecture to deployment. My name is Luigi Milia. I am an automotive industry manager at MathWorks, and I will be your host for this session. Together with me today, we have Jonathan Agg, application engineer from our office in Cambridge UK and Romain Lachaux, application engineer from our office in Paris, France.

So this is our first appointment for this new series electric vehicle modeling and simulation from architecture to deployment, and you can see here the full program. We start today talking about architecture design and analysis, and we continue tomorrow with a session on modeling and simulation of battery assistance. Then we'll focus on field-oriented controls for brushless motors on Wednesday to wrap up with a session on FEM motors with seascape electrical next week. Registration are still open, so you are welcome to have a look at the other session and register if you are interested.

Let me now start with some facts and figures. As we all know, this is another challenging year for the auto industry in Europe and worldwide. And after an initial recovery from the pandemic in the first part of the year, the semiconductor crisis is heavily impacting the second half of this year. In Europe in October, passenger car sales went down 30% compared to the same month in 2020. So the forecast for the full year is still to do slightly better than 2020. But, yeah, we will see. We'll see soon.

But yet if you look at the number from September, the sales of hybrid, plug-in, and full electric vehicles hit another record in Europe. The combined sales of plug-in hybrid and full electric cars went up 42% with respect to September 2020, and the Tesla Model 3 was the best performer across all the fuel types including gasoline. And looking at data for the third quarter of this year, plug-in and full electric vehicles combined have a significant 19% of the passenger car market in Europe.

So the transformation to a new electrified mobility is still accelerating its pace, of course, pushed by upcoming strict emission regulation but also by incentives from governments and also by a shift in public opinion and customer demands for more eco-friendly vehicles. And as a part of the transformation, the marketplace is also quickly changing with an increasing competition among traditional players and newcomers who in some cases are able to attract significant investments and funds. As a result, the entire automotive value chain is adjusting often through partnership and joint ventures especially for researching battery technologies and gigafactories for battery pack assembly. And, of course, this transformation depends heavily on technology, and it poses many technical challenges.

And speaking of technical challenges, the system design of an electric vehicle, the component sizing, and especially the optimization are key factors for the OEMs to offer more range and gain competitive advantages. And advanced software features like artificial intelligence for battery health prediction would be also fundamental together with smart ways to perform the validation of multiple components such as inverters, motors, and batteries. Also new data strategies and new development processes will be required to take advantages from huge quantity of data collected by motor cars so that innovative features can be developed and quickly pushed into production.

So these are the fundamental challenges that need to be addressed to make the transformation to new mobility happen, but there is still one missing key element in this picture. And actually so this element is you, the engineers and scientists who are already making this transformation happen, working with the right tools.

And so before continue with the other presentation, we would love to hear from you. So what are your main challenges related to the topic for today system design and architecture? So you should see a poll open now.

So with that, let me hand it over now to Romain that will start the technical part of this presentation.

Thank you, Luigi. Yes, just a second.

Once again, thank you, Luigi, for great insights in the current automotive market and challenges. So let's now talk about development workflow to help you managing the complexity of electrified vehicles. Requirements is the first step of the development cycle.

And to start let me begin with a quick question based on 2005's study about why do 71% of embedded projects fail. The answer is poor requirements management. If your requirements are not well defined or if they are not traced all along your design process, you cannot produce the right product to respond to the customer needs. That is why having a simple and robust way to manage and optimize your requirements is mandatory. It's a very important point. And so having the possibility to physically link requirements and your design model or your architectural model could be a fantastic way to improve and ensure the trustability of your requirements during the whole development walkthrough.

To illustrate it, I will come back to my previous life Several years ago, I've been programming engineer in a Formula One team. And since 2014, Formula One are powered by hybrid prototype. I will not enter in details, but in this power unit, you can find the MGUK an electric machine that can provide power in power limited sector and so recover energy in grip limited sector.

More especially, a significant part of the brainpower is produced by the MGU kit. It means that you need it to break efficiently the car. All these systems were very new for it and, of course, as usual, time was running out, and we developed the system in a very short time.

And here is what happens at the start of the first phase with this new engine. Clearly, for a first race it was not the good way to begin the season with this complex system. So what happened at the start?

During this start phase, we had an issue with the MGUK IVT sensor. Because of the failure, the MGUK had turned off as expected in the control system so everything was fine on the power unit side.

But as I said before, the part of the breaking power is produced by the MGUK to recover energy during braking phase. And into the brake by wire of controller, this faulty situation wasn't implemented and so the driver didn't have enough brake power to decrease the speed of the car.

Clearly in this case, the main error has been made during requirements definition, and there are two main reasons. First, of course, as usual, we tried to work very quickly. And so we can make mistakes. Moreover, because the MGUK impact both power unit department but also the chassis department we can see here that a lack of communication or traceability between technical teams. It is also a big risk to lose essential information during the development workflow.

Usually we define and manage requirements with an external tool, which can be a generic one like Word or Excel. But it can also be a dedicated one like DOORS, for example.

When I say external tool, I mean that this tool is not integrated in your usual design environment. So there is a gap between the requirements and design platform. So how can we manage this? If you have already requirements defined in an external tool, you can import this requirement in Simulink Requirements, which is a toolbox integrated to the Simulink environment.

So Simulink requirements allow you to import your requirements in the design environment thanks to the ReqIF standard, which is mainly used by requirements management too.

Once you have embodied your requirements, you can also update them automatically in Simulink Requirements if a change occurred in the external tool.

Moreover, you can also edit the requirements you imported directly in the Simulink interface. And you can even create from scratch your requirement directly in the Simulink Requirements editor. And once all these things are done, you can also export everything to your external tool. Thanks again to the ReqIF standard.

But to sum up, Simulink Requirements allow you two things. You can decide manage directly your requirements in Simulink Requirements without external tool or you can also keep managing them in an external tool. And so Simulink Requirements will be the bridge between this tool and your design platform thanks to import and export capabilities.

So here is an example. Let's understand the capability. These are the requirements that are captured in a Word file. These are requirements of a hybrid electric vehicle. I can import this requirement inside the Simulink environment thanks to Simulink Requirements. So how does it look like?

In this tool on the left, you can see all your requirements with hierarchy and different category. Above category, you can manage it as you want depending on the functionality, the physical component, or whatever you want. It's up to you. You can open multiple file of requirements in the same window. Here we can see that I have three requirements I opened.

There will be multiple advantage to integrate requirements in the design environnement. And we will see this joint decision. The first section you can apply to a requirement is to link a requirement with another one. What does it mean?

Well, for example, at the vehicle level, I have requirements related to global inputs of my vehicle controller. Some of these inputs concern my BMS and so I can link a vehicle level requirement to component level requirements. Here are my BMS input requirements.

This physical link, a requirement related to another one, improve the traceability. And so if you change the definition of the first requirement, it will automatically have a warning I think the second one to help you to manage this modification with every possible impacted requirement. And so it ensure a better traceability and so it avoid some error in your requirements definition.

So we have seen that we can import or create requirements directly in Simulink Requirements. So directly within your simulation platform. So now I let the stage to Jonathan.

Great. Thanks, Romain.

So Romain's started us on a journey from requirements to a design. Thinking about requirements, what's the next stage that we might be interested in? Well, it's coming up with an architecture. How can we say what does our system look like and then gradually adding more details and filling in picture so we can understand how our requirements are going to be implemented.

So I want to show you how we can use system composure to define this architecture, whether it's starting from a blank canvas or whether you want to go all the way to adding the implementation. It's going to start out by making an empty System Composer architecture and beginning to fill in some details.

So I'll play this video. Those of who've not used System Composer before, you can start making empty architecture model from the start page in Simulink, go to the System Composer section and say create model. And when we're here, we get a blank canvas, and we can start sketching out like we would on a whiteboard and say what elements do we want to have in our design.

So here we've added in a component representing the environment and another component representing the driver. What else might we need in our now vehicle architecture? Well, some ECUs for the controllers and also something representing the vehicle.

And we can now start adding ports to explain how these components will communicate with each other and also lines to represent the flow of information. So we say we can add an output for the plant where the sensors will come back to the control. We can resize things to make our architecture nice and comprehensible for our colleagues, and we can build up this picture.

So at a high level, these are the important things in our system, and we're now going to start adding in more detail into the ECUs, think about what elements there are in that part of the design.

So System Composer is a hierarchical tool. We can add layers of hierarchy to make our design easier to understand. So if we go inside the ECUs component, we can now start adding in the details inside here. So what controllers do we want? I want something for the engine control. And again, we can define the interface for this engine control.

So we're going to have some sensor measurements coming in, some actuator measurements going out, and also some can communication coming in and out. And we're also going to have as well as engine control some hybrid control, some BMS logic, and likely some transmission control as well.

And we can start joining up the wiring, how is information going to flow around our system, and start sketching this out, saying which types of commands each of the controllers is going to generate and so on, building up the picture incrementally. And we can also add in some blocks to represent the can communication and wire it up to show at a high level how the various controllers are going to interact.

What else might we want to do? Well, we've started filling in the controller hierarchy. The next thing to do could be to fill in the details of the vehicle. What are the high level components in there? And if we go inside, we can do the same thing in here. Starting from another blank component, adding components to represent different parts of the system.

What are their sort of key roles, how are they going to communicate. So we need to have an engine, some electric machines, the motors, some Drivetrain components, and we can also add in a variant component, which is a way of allowing us to try out different components that have the same interface so they do the same job, but they can be implemented differently.

And so for example, in this case, we're going to add a variant component for the battery. Maybe you want to represent the battery that could come from different manufacturers, but we'll see that we could also use a variant to allow us to model components with different levels of fidelity, whether it's a simple battery model or a more complicated, higher fidelity pack model so we can add in the variance inside here.

This is just like a variant subsystem in Simulink if you've used them before. So we could add our options for the different batteries, whether it's a simple battery or a pack battery model built up with the cells that we've characterized. And then we can choose which variant we want to be active. And those of you who've used Simulink before, it's the same way as variant subsystem.

So again, we can join up our components, explain how the information is flowing around, whether it's where the commands come from the ECUs, the different parts of the vehicle where the environment impacts it, and we can also fill in the details that we need to at this stage of our design.

Then we've broken down our vehicle at a high level into these key components and explain how things are going to join together. And we can finish up the final bits of the wiring.

So then we've come up with this architecture from a blank architecture model, we filled in the details, we've seen how it's easy to add components, rename them, add ports, rename those ports, and really express our design within System Composer.

So what are the key components, what are their interfaces, and how are they connected together. That's the really important concepts for doing this sort of architecture work. That's showing quick example of how we can use System Composer to start designing the architecture.

We now want to check that what we've done in the architecture actually will join up to the requirements. We've got the right components in there, and we're not adding them unnecessarily or missing out something important. So how can we understand this traceability from requirements to architecture? The good news is that having requirements and Simulink Requirements and an architecture model in System Composer makes that traceability very easy to add and also to understand.

So here's the vehicle architecture again. We've just added in a few more details in the vehicle model. You can see we've also got our requirements open that Romain was showing us just a few minutes ago.

And we've added in some requirements links from a requirement to the architecture that implements it. And that is a hyperlink that takes us to the right component. You can also see on the component there's this requirement badge in the top right showing it's got a requirement linked to it.

So you've got a nice way of linking between our requirements and the various components. And you can add in links between requirements and other elements in the architecture, whether it's components, ports or connectors to really explain which part of the system is implementing the requirement.

We also get for a requirements set a roll up of how many of the requirements within it have been implemented so we can track the maturity of our architecture and requirements, and understand that as the project evolves.

It's about showing how we can start to add traceability, and we can form links between requirements and architecture models, but also the same requirement linking capability can be used to join up implementation models to requirements. So using one tool can help us improve the understanding of the linking across the sort of lifecycle of the project.

Now another thing we want to be able to do is to define an interface. It's really important to know what elements there are in the design, what signals there are, and how they're propagating around. And as we add more detail, what are their data types? And that's really important step to be getting ready to move to the implementation stage.

So how can we do this? Well, again, it can all be done within System Composer. We can define the interfaces and go from there. So for example, we've made up a data type for the sensor measurements coming from the plant back to the controllers. And we've defined it as a bus data type, representing that there's lots of signals coming out of the vehicle and we want to add in some hierarchy to make it easier to understand.

So we see we've clicked on that port there and it's highlighted in purple. Its interface in this case it's a bus data type called plant out, and that means this is a signal built up with many other buses so we can in fact expand the bus definition.

So that's how you choose the bus there, and then if you expand it, we can see the signals that it's got within it. So there's some commands, some signals coming from the system, others from the environment. And these themselves are made up of further buses. So we can really group our data types nicely and understand the different signals coming in the different parts of the design.

So for example, if we continue within the battery, we can see the signals that we'd expect to see. You've got some voltages, some current, and some temperatures. And we can also add more metadata for each of these to give the individual signals the ranges and the units, and also the data types.

So if we know it's going to be a single in the implementation, we can start adding that information in and recording it in one place. Could also give it a range on the minimum and maximum that it can take, and then we could start building up analysis to check that all propagates sensibly across the architecture.

So that's at a high level how we can define a bus type. And you can do this within the Bus Editor if you've used Simulink before, and you can then also reuse these data types elsewhere in your project within the same elite models.

And like we've built up the signals for the plant here, we could also build up the commands that the controllers will send up, build up a data type for that to record our understanding of the signals that the different parts of the design will be outputting.

That's another really key part of building up our understanding of the interfaces. Again, we could link these back to requirements to check it all, doing what we need it to. But we'll move on to the next stage, which is adding into more metadata into our architecture to give more information on what the components do, what is their role, and how they're going to meet their requirements. And we're going to do this through stereotypes.

So System Composer lets you define stereotypes. So we can start adding in more information, whether it's on a component, a port, or the lines, the connectors, and we can extend and give them new properties with stereotypes. So why might we want to do this?

Well, for a component that's representing a software component, we might want to record who's its owner, what's its ASIL level, and maybe some other project management status within that stereotype. Or if we've got a component that's representing a physical component, we might want to record information about its physical characteristics.

What part number is it? Maybe we've got a part database we can reference or maybe we want to record what's its power consumption or how much it costs. Whatever is useful to be able to record alongside the architecture, stereotypes letters define these. So let's look at some examples.

Maybe we've got a component for a battery and we can record that it's coming from a particular supplier, costs this amount and weighs this much. But maybe if we're working with a BMS there's sort of two aspects to it. Part of it is related to software so we add a stereotype for that. We can also add some information about the hardware that this controller logic will be implemented on. So this is adding information about the ECU. And you can mix and match stereotypes depending on what you need.

The really key bit is that this information is being recorded alongside the architecture. We're not having to keep track of these two things stored in different tools. They can all be put in one environment.

So we've gone through building up an architecture, defining the interfaces and some stereotypes. Another key systems activity is defining the allocations between different architectures. So we're now going to explore the capabilities and System Composer for this.

And although System Composer doesn't define a workflow that you have to follow, lots of our customers follow the fairly conventional way of starting out with a functional architecture where you capture what the system needs to do, moving to a logical architecture where you say what components there are in the system and how is the information flowing between them, and then finally linking down to a physical architecture or a platform architecture where we want to capture what will actually be in the system.

These are kind of adding in more details, and we want to be able to be sure we can be consistent between these different architecture models. And how can we help with that consistency? Well, this is where allocations come in.

It's a way of adding a link, sort of like a requirement link, and a special kind of allocation link to go from one component to another in a different model. So maybe we want to record this controller in the logical architecture will go into this ECU, and this sensor will go into this set of sensors. So we can build up our understanding, make sure that we've allocated everything sensibly.

So we can use the allocation editor to record this. This is part of System Composer. We've got a functional architecture in blue, and a logical architecture in green. We can add in these allocation links using the Allocation Editor and start to understand how we've done our design.

And because this is all based in MATLAB, we can process this application and start doing analysis so we could check how much memory are we using on the ECUs or have we overloaded one ECU by allocating too many components to it and so on. This is all querying that information stored in the stereotypes and using that along with the allocation to answer these useful engineering questions.

So that is a sort of brief example of an analysis we can do with MATLAB. There's plenty more that we can do so we're now going to have a look at some more examples, ways we can analyze our architecture using MATLAB and start to optimize it, make sure we come up with the best architecture we can.

Because System Composers built on Simulink, which itself is built on MATLAB, we've got access to the great range of mathematical functions available, and that's an optimization software or doing some graphing analysis. We can really use all of that capability and benefit from being in the same environment.

So what analyses can we do? Well, anything we can think of really because we've got our information available, we're capturing it as properties within stereotypes. For example, for a vehicle, we might want to capture its cost and its weight like we saw before.

In the Analysis Viewer in System Composer lets see the various properties that we've defined for our components within these stereotypes. So in our vehicle example, we've got different components on the left here. And because they're all representing different things, they've got different stereotypes. So the physical components have the power and capacity, especially for the electrical elements.

So for example, we see this motor is using this much power, and this battery has got this much capacity. And if we had multiple batteries, we'd see multiple elements in this column. And on the right here, we've got the cost and the weight. So more elements have got these stereotypes defined for them so we've got more elements populated.

And what might we want to do here? Well, we might want to find out our overall system cost or the overall system weight. And we can write in a few lines in MATLAB an analysis function that will do that roll up analysis for us and tell us the overall cost both for a sub system but also for the system as a whole.

And this is all using the capabilities of MATLAB and System Composer. And it's a nice example, helping you get started as well if you're not sure how to do this. So the rolled-up results, give us the system status.

And this capability also allows us to try out different designs. So maybe we want to see what happens if we change the cost of a particular component. What's the impact on the overall status? And we could make a change, run our analysis, see the overall system behavior. And if we like it, we could update that value within the stereotype within the model, and then save it or we could discard it if we didn't like it.

And because this has all been caught using MATLAB functionality, we could wrap this up in a MATLAB optimization server and ask it to come up with the best configuration it can find to optimize some cost function based on some set of constraints, or trying out different ideas and seeing what is the best architecture it can find.

So really, this is sort of a nice, simple example, but the possibilities really are endless. And we will be very happy to discuss any ideas you have for using an architecture model within this sort of optimization. It's a really exciting possibility.

We saw at the start we were building an architecture. We've seen how we can add some allocations and starting to analyze it. And an actual question, as this architecture gets bigger, how can we keep the clarity of our understanding of what's contained within it? Well, this is where views come in.

It's a way of filtering down the information that you see to be answering the question that you need to try and get the key information visible and to hide things that are not relevant for the engineering activity that you're doing.

So what is a view? Well, it's a way of saying which components and which lines in architecture are you interested in looking at. We can hide away things that we're not interested in, but there's no risk of getting duplication. A view is really just a filter into the original model.

So we could say, I want to see a flattened view of all of the components, to break down the hierarchy, and be able to see how lines get traced across component hierarchy boundaries. But it's still quite a lot of blocks here, quite a lot of lines that get harder to understand this as the system gets bigger still.

So that's where coming up with a way of filtering the information down. Maybe we just want to see all of the controllers or maybe we want to see a hierarchy diagram. So instead of using a component diagram, which you see here, we can get this hierarchy diagram on the right. This is all built in.

And we get a nice summary of the interfaces and also the stereotypes all in one view. And you can see how different components can have child components, and review their stereotypes and interfaces, and check it's all making sense.

So this is all built in. And once you've got a view, you can make these. But how can we make a view? Well, there's two main ways. The easiest is to make a spotlight view where you click on a component and ask to see all of the components that it's connected to. And that can help answer questions like, if I change this component, what else is going to be impacted in the system?

But you can also define more complicated views using the view filter capability. And this lets you query the metadata stored as stereotypes and work out what components are relevant and building up a view based on that. So for example, here we've got a line that says choose all the components where mass is greater than 10 kilos.

So maybe this is a good way of finding all the heavy components. So if we're interested in optimizing the weight, we could run this view to get the list of the heaviest components. Or maybe we want to find all of the components related to that particular part of the system. So we could search for all the components that have an interface of a particular type or a stereotype of a particular type and then build up a view based on that.

Here's also another special point of view called sequence diagram. And there's a nice way of doing these within System Composer. That means you're going to stay in sync with the architecture. There's no risk of your sequence diagram getting out of sync with the main design, which is a common challenge we hear about with other tools.

And what does this sequence diagram look like? Well, if we've got a functional architecture and various components within it, this case, this is a tire pressure monitoring system. So we need to be able to measure the tire pressure, check whether the pressure's OK, and then report that status to another part of the system.

And we can build up a system sequence diagram that can represent this and understand what messages are being passed around the system. Based on the lines in our architecture, we can build up the spew.

So suppose we wanted to add a new lifeline into our sequence diagram. That will automatically add in a component into System Composer. And if we add in a new line between these lifelines, that will add in an appropriate line within the architecture representing that new bit of information flowing between these two components.

And if we delete a line, the consistency check will highlight that that component has been deleted and that our sequence diagram now needs to be updated accordingly. This is a way of getting a different view of the system. In this case, how the messages are being sort of passed around. We've seen this, a real, nice, tight link between the original architecture and this view.

So the final of capability I want to mention now is the linking from the architecture, the design. And it's really important so we can understand the flow from requirements, to architecture, to implementation. And then if we get this good linking, then when the requirement changes, we've got a much better idea of what needs to change within the architecture. And then using this linking, understand what needs to be updated in the implementation accordingly.

So how can we do this? In all the uses of System Composer so far, we've just been making some components in the architecture and they're representing a component, but it doesn't have any implementation behavior. But if you right click on a component, you can choose to either create an empty Simulink model with the same interface as the component, or you can link to an existing model if you've already made it or one of your colleagues has already made it.

There's also ways of making a Stateflow chart within the System Composer architecture. This could be good for doing sort of higher level system design in Stateflow, maybe not the final implementation with all the co-generation details, but representing the main modes of operation. Or we can link to a Simulink model that is ready, either the co-generation if it's for a controller or linking into physical modeling within Simulink and Simscape.

And plenty more details on that coming up in the rest of this presentation. For now, before I hand back to Romain, just want to summarize what we've seen so far. We can start from the stakeholder needs. It's always important to make sure the system is doing the right thing. We can develop requirements in the Use Cases to capture all of that understanding.

From there, we can build up an architecture and link back to these requirements. We can add the metadata, the stereotypes, check we're understanding the system, how it's doing. We can start optimizing those parameters, and then develop different views to see our system in the ways that are useful to express the key parts of the system, depending on what our role is or what our job is that particular day.

And then we started seeing how we can link to Simulink. And then based on this linking, we got a really strong case of, whenever climate changes, what is the overall impact.

So now I'd like to hand back over to Romain. If you've got any questions, please do put them in the chat. We'll be very happy to go into them at the end.

OK. Thank you, Jonathan.

So if I sum up for now, we have seen how we can manage requirements in the design environment. We have also seen that we can create architectural model with System Composer. We can also link requirements with this architectural model, and you can also define and synchronize behaviors with your architecture. So let's see now how we can handle with system and component design thanks to model and simulation.

So which questions are still unanswered? Here are some of these questions. First, what would be the energy consumption of my vehicle on the drive cycle? This is a very important question nowadays because of environmental situation, energy price, and so it's a big selling argument.

You want to observe and analyze the behavior of your vehicle and its components in various road conditions. Indeed, you would sell your car in Scandinavia, but also in South America or Australia. Moreover, you have a different type of driver. You have the smooth one and also the racing driver. Or just to say that your design should be able to support all these operating conditions.

And because we are using potentially a different type of energy, you need to create complex control system to handle and optimize energy consumption. And this complexity is a big challenge because it means that you cannot wait to have a real hardware prototype to start testing and validating your design.

And that's why we encourage you to fully adopt model-based design. What we mean by that. Maybe you are very familiar with this term or maybe not. I will not give you a full view of the model-based design now. It's not the purpose. But to make a quick, model-based design means that you will perform as many activities as you can based on a model of your system that can simulate and analyze the behavior.

If you want to improve your knowledge about it, I encourage you to read this short book available for free on our website. And so this model-based design can be, of course, applied for xEVs. Indeed, with the simulation of a vehicle level model, you will be able to take your main challenges like benchmarking with existing vehicle on specific drive cycle and determine requirements for electric drivetrain.

You can also use simulation to choose which technology or which component is the best for your application. You can also perform as many simulations as you want with different load, different lifecycle to ensure that you will meet requirements without advertising a component.

And you can also perform vehicle level simulation to analyze the behavior of the system and optimize both control and other parameters to comply with requirements and standards. These are some usual changes, but, of course, there are a lot more.

So I think you have understood that a model of your design and the simulation of this one is the cornerstone of model-based design. Let's understand the approach. For motor oscillation, we need to decide whether we should use a BLDC induction method or SRM, et cetera.

How do we decide that? By simulation. Where do we simulate the motors in the vehicle level motor. We need a result of values model that's available as components so that we can replace the motor and do simulation-based experimentation. This way, we can also vary various component parameters and perform experimentation.

So not only component selection, but high level component sizing can also be done. And what is true false, but to us is true for every component like the battery. With the vehicle level model, you can quickly have some main ideas about the capacity you need, for example, to meet requirements of performance in the range.

To do this, you can use an average model with a simple battery model based on the experiment. And then you can also use a more detailed model because we know that a battery cell behavior is complex with a lot of variation depending external condition, state of charge, and aging of the battery. So on this slide, I just show you some component block like motors or batteries. But as I said, the idea is to integrate this in a vehicle level model.

And so here a vehicle level model. The input of this model is a drive cycle. Here we have the FTP75. We have also a driver model to allow you to follow the drive cycle as defined. You have also environment parameters like wind, pressure, or temperature.

And finally, we have also controllers and passenger car. And this is the first major advantage. In the same simulation environment, we have both control algorithms and physical model of our vehicle, which means we can effectively perform close loop test with our model.

So in the controllers, you will find, of course, engine control, battery management system, or regenerative braking control. And in the passenger car, you will find main components of xEVs like the electric motor, the battery we just discussed before. To build this type of model easily and quickly, you can use prebuilt components in library that you could assemble.

For example, you could build your thermal engine model of turbocharger, intercooler, and manifolds. Then you could integrate this in the vehicle models with wheels, chassis, Gear Box controls, driver model, or drive cycle as presented before. And once you have this model, you can simulate it and observe the behavior of your design on the drive cycle you choose.

Here we can see a comparison of the actual speed vs target speed to be sure that you are following your cycle. You have also the thermal engine speed and the electric motor one, the state of charge of the battery on the cycle, and also the fuel consumption. So as I said, this model can be a good basis to start and make strong architectural and sizing choice.

The good news is that you can find this type of library in the Powertrain Blockset, which is a toolbox fully integrated in the Simulink environment. And I can add that maybe the most interesting point that you have also with this Powertrain Blockset several reference application that can be a very good starting point for your project.

As we have seen before, you have in this reference application both controller and plant in the same model, allowing close loop testing very easy. Moreover, these reference applications are fully open, which means you can easily customize and adapt it to your application.

And also, I would like to add that these model are optimized to be very fast, which is a good point for iterative activities like perimeter sweep. But there's a very important point. If you want to deploy it on a real time machine for hardware in the loop testing, for example.

So as I said, you have both library with several blocks to model different components of the vehicle, and you have also reference applications for conventional vehicle. So I mean, with thermal engine, spark a compression ignition. But there's also a hybrid vehicle with different architecture. We will see this in a few seconds. You have also a full electrical vehicle and also a vehicle with a fuel cell.

So you see that you have a reference application for almost every type of vehicle. You have also NG Dynamometer to test and calibrate our engine model. All these models are really great to start, to build your own vehicle level model.

In the case of HEV, as I said, you have several architecture possible, depending the location of electric machine. This position is indicated by P0, P1, P2, P3, and P4. And with Powertrain Blockset, all these architecture are available. And thanks to the value functionality, you can even store all this architecture in a single model and switch easily from an architecture to another one.

And so once you have your model and your design, you can, of course, execute it and analyze the behavior in normal condition. But this is the beginning of your journey. Indeed, with this model, you can then optimize it based on simulation.

For example, you can use optimization tools to maximize the fuel economy on some specific drive cycle. You can also try to minimize the time required to reach 60 miles per hour by optimizing operating mode boundary. These two criteria can be hard to define because there is the possibility to improve one by decreasing the other one. And so tradeoffs today based on simulation is very important.

And even if it's not the purpose of today, we have tools that give you the possibility to find more or less automatically a set of parameters value to optimize cost function that you have defined. It's very powerful.

You can also start your drive cycle with different state of charge and see how your design deal with this difference. Suppose that my battery isn't fully charged at the start of the drive cycle. Is the VCU able to take care of this situation? Is the VCU able to switch in different mode in a start and smooth manner. The stimulation is a great way to ensure that it's possible.

And finally, on the architecture and component sizing side, you can, for example, perform if there is some tradeoff on the battery capacity and the cell configuration. What is the right capacity to achieve performance and range you define in your requirements in multiple operating conditions? What is the right number of cell and should you connect them in series or parallel?

And all of this is not simple to do without simulation. Because this has a direct impact on the mass of the vehicle, which will have a direct impact on the performance and the range. And so the vehicle simulation is the right tool to prevent a vicious cycle.