Software-Defined Vehicle Realization with Model-Based Design and FEV’s Gateway - MATLAB
Video Player is loading.
Current Time 0:00
Duration 14:59
Loaded: 1.10%
Stream Type LIVE
Remaining Time 14:59
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 14:59

    Software-Defined Vehicle Realization with Model-Based Design and FEV’s Gateway

    Dr. Hamzeh Alzubi, FEV North America

    Emerging technologies such as artificial intelligence (AI), connected and autonomous vehicles (CAV), and electrification motivate the need for a new EE architecture that can handle the complexity of these systems. SDVs are key enablers for these technologies in the automotive industry. However, SDVs come with challenges including legacy software adaptation and high-performance computer (HPC) testing. FEV can help with overcoming these two specific challenges by utilizing MathWorks Model-Based Design tools and FEV’s Gateway. Hear about two use cases that highlight the effectiveness of FEV’s approach towards a rapid realization of SDV software development and testing. The first use case illustrates migrating a traditional legacy E-drive torque path function to a service-oriented architecture (SOA) for SDVs. The second use case demonstrates the integration of an SDV HPC with an existing EE architecture using FEV’s Gateway for rapid integration and testing.

    Published: 14 May 2024

    Yeah, hello. My talk today will be about how FEV IO will show the approach of transitioning from existing or conventional architecture and conventional software development to software-defined vehicle. But before that, let's go through the agenda. We'll have a little introduction here, then we'll talk about the motivation for SDV. Then, I will have two use cases to talk about, one with the HPC software development and the other one of how we use FEV gateway to realize testing of HPC software-defined vehicle.

    As you know, over the time, EE architecture was evolving due to the complex additional features with the emerging technologies, like back in the days, we have that conventional architecture, that distributed one, with many ECUs. And when we add additional features like ADAS connectivity and AI functionalities. That means you need to add more ECUs, making the EE architecture more complex. And, with time, like we have seen the domain controllers that consolidated the hardware, and then there is a need to come with the zonal controllers, and finally, the centralized one which paves the way towards the SDV.

    And one example I want to talk about how connected and automated vehicles also showed us a very good example about the need to move for a software defined vehicle platform that can introduce the flexibility, having the over-the-air updates, and many, many other features that SDV enables for the development. We can see here, Amazon car has about 150 million lines of code, hundreds of ECUs, and also the need for a cloud and the big data that introduced due to the different kinds of sensors, especially camera, LiDAR, and radar.

    Now I want to talk a little bit about the motivation, why SDV is seen as an enabler, let's say, for those emerging technologies. When you look at the EE architecture-- like, this is just a small section just to show the complexity in the hardware-- you can see we have this distributed EE architecture with many legacy ECUs and how the software-defined vehicle focusing on the centralized high compute with some zonal controllers that will manage the communication with some of the legacy ECUs and other sensors and actuators.

    Benefits of that-- you can see the low cost, less weight, faster time to market. And one of the big advantages for SDV is the decoupling hardware from the software. And also, it enables other technologies. As I mentioned, it has electrification and connectivity.

    I will start now with our first use case. FEV.io, a global engineering services, focusing on providing software solution or services-- we provide cutting-edge EE architecture and software solutions and pave the way for transferring or transitioning to SDV.

    One of our first use cases is about-- if you already have legacy software and you start thinking about how you will migrate this software to software-defined vehicle, this use case specifically talking about that. We have built a demonstrator we showed at CES this year. It has mixed criticality loads, between infotainment, ADAS, vehicle control unit, and the cluster instrument. And also, in this use case, we focus on showing how we are migrating legacy code to service-oriented architecture. And finally, we show our IB virtual bus that enable the communication between different virtual machines within the hypervisor.

    What we see here on the left side, it shows our bench setup that has the infotainment screen, the cluster screen, and we use CARLA simulation to validate our development. And in the right side, we see the animation we built. Because when you look at the bench itself, you feel it's a typical development. With this CARLA simulation and scenario, we show adaptive cruise control with cut-in scenario and how the vehicle is keeping a safe distance.

    But when you look inside more insight about the high compute, which is the animation we developed here just to clarify we are talking about software-defined vehicle is not a typical ECU or typical ADAS ECU we develop nowadays. You can see we have used-- we are using a Renasas high-performance processor. On top of that, we have used a QNX hypervisor. QNX enabled the communication between the external hardware, like the screens we have CARLA, PC, and the gaming controller that is used to communicate the information with the virtual machines.

    And, on top of that, we built our virtual bus that enable the communication between those virtual machines, which is the vehicle control unit, the cluster, as I mentioned, ADAS and infotainment. And within the virtual bus, we are enabling the communication or the data conversion from DDS and SOME/IP protocols.

    Also, I want to highlight, within this HPC demo we developed for SDV, our use for MathWorks tools and how it was used previously with our legacy ECU and how, then, we transferred the software to the SDV domain.

    Now what you see here, as service engineering company, we try to show different kind of technologies at the hardware level and at the software level. If you are wondering why we are using adaptive AUTOSAR at one virtual machines and other without, just we do that on purpose just to show the capabilities in different domains.

    And we have different hardwares we use. Renesas is our main platform, as I mentioned, for the HPC. And NXP we used just to build the Android automotive HMI. And we used MATLAB Simulink initially to develop the torque path, which I will talk about in the next slide. And then we use the AUTOSAR Toolbox, then, to adapt the algorithms from the classical AUTOSAR to the adaptive AUTOSAR and then implement it within the virtual machine. So legacy was C, and the new development is-- the generic code in C++.

    This is the path I was talking about, which shows all those inputs coming from DDS network and was converted to SOME/IP. And there is a communication between, also, the VCU virtual machine and the CARLA simulation that handles-- our virtual bus also handles the communication or the conversion, the data between DBS and SOME/IP. You can see MathWorks tools mainly was used for the model itself and interfacing the services between the virtual machines.

    This shows a high level of our workflow. We started with using a vector tool to define the requirements, use cases, and then we used MATLAB Simulink to do the design, the adaptive AUTOSAR service interfaces. Then, we have generated the code and integrated that within our hardware in the loop setup I showed early.

    Just to have more insight about how we use MathWorks or Simulink, if you are familiar already, like you go with to the abs, you open the AUTOSAR component designer, and within that, you start integrating the ports and the send event and receive event just to convert between service to signal.

    Because as I mentioned earlier, we are utilizing an existing legacy Simulink model we developed for the torque path. We are taking that as is, and then start adapting the input/output to be service-oriented input/output. And, within that, you use the AUTOSAR dictionary to configure the attributes for the model. Once that's done, we use Embedded Coder to generate the code, and it needed to be adaptive AUTOSAR and C++.

    This concludes the first use case we had that shows our focus on developing software-defined vehicle for high performance compute. Now I will transition to our second use case, which currently, we are helping one of the big OEMs and supporting them in validating their SDV HPC development using our FEV gateway.

    The way we help them with that, they provided a vehicle they have now with existing EE architecture, and then they provide their HPC and zonal controllers to us. And instead of building a new, from-scratch EE architecture, they asked us if we can help them in integrating this HPC and zonal controllers on an existing EE architecture, which we use our FEV gateway to make the interfacing and message translation between the zonal controllers and the legacy ECUs for the EE architecture.

    We handled the hardware aspect as well as the software-- like, we programmed the gateway to make sure data synchronization, events, everything working very well to avoid any DTCs and enable the communication between the HPC and the rest of the vehicle sensors and actuators. And it's a very successful way, I think, to do vehicle-level testing for HPC.

    Now, finally, I want to talk about, as a summary, let's say, for this presentation and what we offer for our customers. As I showed, we have used different kind of tools for our demo built between MathWorks tools vector, like Linux GNX and Renesas and other hardwares we use. And what we are trying to show or the message here-- if you have legacy software and you want to move to SDV platform, we can help with that, and it can be done with efficient way as well.

    Also, as I mentioned, we heavily use MathWorks or model-based tools for our development, and we can support other activities within the HPC, including HPC board bring up, hypervisors, functional safety, cybersecurity, development, et cetera.

    One last thing to mention here-- we do have this platform we use for ADAS development and connectivity. It has drive-by wear capability and a lot of has sensors, radar, LiDAR, camera, GPS, and different kinds of sensors as well. Now it's becoming a platform for software-defined vehicle development and testing by integrating additional HPCs. And we are trying to apply same technologies we did for the bench on the vehicle. So we have the capability of doing vehicle-level testing.

    And conclusion-- as I mentioned at the beginning of the presentation, we see that the EE architecture is evolving every day due to the complexity of the new features, which move us towards we need to consolidate the hardware, finding an efficient way to do the deployment, which lead us to think about having a SDV EE architecture or platform that can support the autonomous connectivity electrification and enable scalability for those features over the air updates as well.

    And we have seen, from our experience with this SDV we developed, we can move the legacy software to SDV platform efficiently with the maximum use of the legacy software. And it is proven our gateway is a key enabler for SDV development and testing. And, of course, it is well-known, but just to talk about it again, MathWorks provide the needed tools and support during the development, and transitioning from legacy software to SDV.

    Finally, if you need any help, we can be your partner for any emerging technology, like SDV. And we're here-- you have any questions?

    [APPLAUSE]