Automotive DevOps for Model-Based Design with AWS, NXP, and MathWorks

So for today, what I would like to communicate with the audience is on the Automotive DevOps Solutions for Model-Based Design. As Wensi said, my name is Curt Hillier. I'm a Technical Director with NXP. And I'm in the automotive systems engineering group.

OK. Need to see if I can get that out of the way. There we go. OK.

So for automotive industry trends, vehicles are undergoing a transformation, from mostly mechanically defined features and capabilities to software defined. The key trends that we see in the industry to support that transformation are the transition to continuous integration and continuous delivery workflows, increased size of software development teams, a migration of tools and workflows to the cloud, and then the continued adoption of Model-based design engineering.

NXP, the MathWorks and AWS have collaborated to build an example Automotive DevOps solution, which can enable the future of Model-based design. The goal is to let your developers and your coders do more development and coding. So for the solution that we will discuss today, it incorporates the AWS, Amazon Web Services, code suite products, the MathWorks Model-Based Design tools, advanced vehicle control algorithms executing on an NXP automotive processors to round out the group.

The solution allows users to develop and simulate in the cloud, and then easily deploy to automotive silicon for algorithm validation. If we look at the application and how it's built, we have the AWS products at the top for the-- called CodePipeline. They allow you to train, build, and simulate. The second major group of functions is the MathWorks tools that support model-in-the-loop and software-in-the-loop simulation, coupled with the NXP MBDT.

So those are the tools for designing, simulating, and implementing automotive software and system models. The NXP Goldbox is where we execute our algorithms on automotive processors. And we can use a profiler to measure execution time. And then finally, we have the AWS IoT solutions, which completes the life cycle, and allows you to take vehicle data and publish it to the cloud.

Get that to go away. Solution Products. First, we'll talk about the AWS products. Why do we choose to work with AWS? They have numerous solutions for connected vehicles and continue to deploy additional products. They're strong at collaboration. They develop those leading-edge solutions. And they are easy to use-- good documentation and support.

The two products we use are the AWS CodePipeline-- that's for the fully managed continuous delivery-- and then the AWS Greengrass and IoT Solutions. The CodePipeline is operating in the cloud. The Greengrass grass software operates on the vehicle edge, inside the S32G processor. And then the IoT Solutions, again, are operating in the cloud.

The MathWorks-- why do we choose to work with the MathWorks? As many of you know, MathWorks has broad domain expertise, across virtually anything you'd like to do. MathWorks has experts that can support you along the way.

The toolchain for software and simulation development is very powerful. Visualizations are very powerful. And they make it quick to get started. They have prebuilt examples that have good quality and documentation. The products we use are Simulink, the Powertrain Blockset, Vehicle Dynamics Blockset, and the Embedded Coder. It allows us to build a car using a prebuilt model, generate C code, and then run simulation.

So a few more notes on the Powertrain Blockset-- it provides a library of blocks and, as mentioned, prebuilt reference applications. We use the hybrid electric vehicle P2 reference application that's already built for you. It saves quite a bit of time.

If we look at how those applications go together, you have library of Blocks. Those Blocks are built into-- used to build a system. In this case, a combustion engine. And then that combustion engine goes with the other pieces of the vehicle to build a plant model of the car, controllers, and then stimulus, and then finally the Visualization Blocks. So that's your built example. When you run it, you have a trace velocity, engine speed, motor speed, battery state of charge, and a fuel economy that come out through the Visualization Blocks. It's a very powerful way for us to get started, and to take a controller algorithm, generate code, and have that run on our target processors.

So if you look at the NXP products, the Simulink model that we just talked about is up here at the top. And then we use a codegen process out of the MATLAB products to generate C code. That C code is coupled with the NXP Model-based Design Toolbox and, in this case, the high performance computing platform, to build an object file that can execute on the target hardware. In this case, the HCP supports our gateway products in the S32 Goldbox.

Our vehicle electrification control systems using the S32S GreenBox 2, as well as some of our RF products that aren't shown here. So the NXP product brings the power of Model-Based Design to the NXP automotive real time processors and vehicle network processors. It's excellent for early prototyping and performance measurements.

So now we can go into a demonstration that we've put together. Here's a little more detail on the life cycle. We've got a CodeCommit with the AWS products. You check in your changes into GitHub or Bitbucket. There's a build process that you can launch. In this case, it invokes the Jenkins build, and that pulls in the MATLAB tool chain, as well as the NXP and BDT. We can next then deploy it to target and then run our processor in the loop simulation with all of the simulate built in GUIs.

For any of you that have installed tools and compilers and multiple versions of those, you know they take up a lot of room on your hard drive and they take a lot of time to maintain. So this is a build once in the cloud and then utilize for a large group of developers. That's how we let your developers continue to do more work.

The next slide, we've taken the local PC that was running the processor in the loop simulation, and that can actually be migrated into the cloud. And the PIL process can be initiated from the simulation running in the cloud. And so we have both configurations that are operational. And in both cases, the controller code that's generated runs on the S32G GoldBox. We publish data into Greengrass, and then push it back into the cloud to complete the lifecycle.

So here's an example of the AWS products. You'll see a CodeCommit step that was successful, a Jenkins build, and again, that's the one that launches Simulink, the MATLAB codegen and the NXP and BDT to create the object executable, and then finally, there's a deployment step down to the target hardware.

If we look at the output of the Jenkins build, you can see that we have created our .efl file, you have some data on the size of that file for the code and the data that's used, and then finally, this is indication here that the AWS CodePipeline process has completed. So we have a successful build and an object executable that we can use.

So from this step, what we've shown, everything that's operating in the cloud here is up to this point. And then we will deploy it to the vehicle hardware, the S32G2 GoldBox. The code will run on the Arm Cortex-A53, and the code that's operating is an energy management system. There's two flavors of that. There's an adaptive ECMS, Equivalent Consumption Minimization Strategy, and then there's also a model predictive control application that we've developed.

In both of those, look at cost optimizing your control system such that you maximize your range. You look for the optimum point for the combustion engine and the optimum operating point for the electric plant. And we'll see that in a simulation here. We are using a standard drive cycle, FTP-75, and we use just a few seconds of that drive cycle to speed up the simulation.

So here's an example of the demo in operation. This is actually running the calculations on the vehicle hardware. You can see that we have the vehicle speed, the desired speed and the actual speed, the engine speed and the motor speed, and then the results of the energy management algorithm are the engine torque and the motor torque. You can see the motor torque is in blue, and whenever that torque goes negative, we're regenerating the battery.

You can see the corresponding data here on the battery current. When it's negative, the battery's state of charge is increasing. And then you have a fuel economy chart down here at the bottom. So it's very powerful. And one of the things that I'll show you next is the ability to-- excuse me-- gain profiling information.

So when the simulation finishes, we get a profiling report that pops up. You can click on this button here and it shows you all the results for your execution. So we end up with the target application, and we get an average execution time and a maximum execution time.

So we're running at about 10.7 milliseconds per iteration as an average and a maximum of 13.9. We're operating on a 100 millisecond time frame. So we have plenty of overhead in this application on the hardware. And that's excellent. That gives you confidence right away that my algorithm will fit in my target hardware.

Here are some additional results that if I were to click on this button right here, the histogram and then the chart, I can see the execution time at every time step, every 100 milliseconds, and then this is the histogram of my execution time and how it varies from instance to instance.

So now that that's completed, let's recap on what we did. We did a CodeCommit using the AWS tools. We did a code build that launched the Jenkins server and kicked off a MATLAB instance to do the simulation and the build of the target file. We deployed that target file down to the local machine for deployment. And then we did a processor in the loop simulation that you just saw the results from that.

What we haven't shown that we have in other materials is that publishing of that data up to the cloud. And there's a link at the end of this presentation that you can click on. And that'll show you the additional portion when the data goes to the cloud. Again, we are designing, building, and simulating in the cloud, we're deploying to the automotive edge, and we're integrated with the Greengrass components in the target hardware.

So at the beginning of the presentation, we talked about trends. That we were transitioning to CI/CD in automotive that can be supported by AWS CodePipeline products. We have larger and larger software development teams. And do you want every developer to have to manage all of their own tool chains on their own system. And that's where we can see this cloud migration using cloud solutions from AWS can provide a benefit.

We've got migrations of tools and workflows to the cloud. And what we demonstrated was the AWS was hosting the MathWorks in the NXP products and tools, and then continued adoption of Model-Based Design engineering. And that's supported by the MathWorks tool chains and the NXP and BDT.

Finally, we talked about real world benchmarking. So we did edge deployment using the Model-Based Design Toolbox. And we ran our code on an automotive vehicle network processor. And we were able to see real world benchmarking off that target.

So here's your links for additional follow up. We've got the GoldBox product that's listed here, the GreenBox product, the Model-Based Design Toolbox, and then finally, a link here to the demo that shows you the data publishing side of our solution. For AWS, we have links for CodePipeline and the IoT solutions. And for the MathWorks, this is a nice article that's written on the virtual vehicle. And it walks you through how that's put together.

For follow up, you can contact me or your contacts at either AWS or the MathWorks. And I think I've got one last slide. And this is a plug for the MATLAB Expo. For more details on the Model-Based Design Toolbox and how it's built and its purpose and an additional demo, you can join the MATLAB Expo. And we have two of our engineers that will be describing the rapid prototyping using MBDT. OK, with that, I'm finished. I think ready for Q&A.