SDV: Integrating Simulink C++ Generated Code in Android Automotive Environment
Rémy Brugnon, Renault Group
Accelerate the development of software-defined vehicles with Model-Based Design and integration of Simulink C++ generated code in the Android Automotive environment.
Published: 7 Aug 2023
I'm happy to be here to share with you a bit of experience we had using MATLAB Simulink in a software-defined vehicle context. So my speech will introduce the software-defined vehicle context at Renault. Then I will switch to proof of concept we have realized to connect models using MATLAB Simulink in Android environment with interprocess communication.
Then I will present to you a demonstration with a climate control system use case. And I will end with a conclusion.
So the overall vision of Renault, as it was said previously, is a centralized EE architecture with a high-performance computer at the center communicating through Ethernet network with zonal ECUs, mostly Classic AUTOSAR ECUs and driving sensors and actuators.
So on the software plane, the change is to switch from a signal-based architecture to a service-oriented one. And that is involving system engineering and software engineering also. And the promise is to obtain a scalable and upgradeable platform at the end.
So a few years ago, we launched an upstream project named FACE for future architecture for automotive computing environments. So introduced a new development flow which is top-down flow, seamless, from system to software implementation in all areas of automotive domains-- body, ADAS, and chassis.
So at that time, we were targeting to use adaptive AUTOSAR on high-performance computer. And the architecture was all service oriented-- so client server-- using request/response methods and events. So the software architecture on the top right was done using a UML tool customized for Renault.
We extract from this a definition of software components and interfaces using Franca IDL-- IDL for Interface Definition Language-- which is used in AUTOSAR standard. We transformed this IDLs in AUTOSAR XML software component description using a Renault tool.
And then we import it in MATLAB Simulink, realize the model, and generate directly the adaptive AUTOSAR code. So that was the plan. Then we move to software-defined vehicle. And as project preparation, there have been some slight modifications.
So first, we had a strategic collaboration with Google. That means that we replaced adaptive AUTOSAR with Android Automotive OS. That is a big change. So this implies also a new Android IDL, Interface Definition Language, which is necessary for defining the interprocess communication. But we maintain our service-oriented architecture using remote procedure call and callbacks.
So that means for the thing I will present to you, we generated code using the embedded code of C++. We translated the Franca IDLs in Android IDLs. Manually, we made binding-- AIDL binding between Android and the model code to make an Android module, an Android application.
Now I'll switch to the technical part. So how to connect the code generation from models to Android IDLs using Android binders? So I will start with the MATLAB Simulink modeling. Then I will switch to the code generation and the glue code that is necessary to connect the two worlds.
So in MATLAB Simulink, so it is a very simple example I've chosen for to be clear. So you have the client side and the server side. We are defining a very simple interface with only one method in it. So in the client side and in the server side, we use the function elements, which were introduced in 2020a, I think, in MATLAB Simulink.
And from the client side, we use a function caller and, from the server side, a Simulink function. When we generate the C++ code in the Simulink world, we have this representation. So it's a UML class diagram representation, where we find the two classes, main classes-- the client class and the server class.
And MATLAB Simulink is defining its own interface. So it's the green box, which is used by the two classes. In the Android world, when we have defined the Android interface definition language file, it generates a binder on the right, on the server side, and an interface on the client side.
So what we have realized, it's only a kind of glue code or wrapper-- so implementing the interface, the binary interface, on the server side and using the interface at the client side and calling the model. So now I will switch to a bit of code, piece of code.
So I have to precise that in the presentation, I've only used the open-source version of the APIs. So on the server side, we implement the binder. It's just using the model code generation. And we offer the service Android service offering using the addService API.
On the server side-- on the client side, sorry, we realize we implement the interface, the MATLAB Simulink interface, using the Android interface and finding the service using the waitForService API.
OK, so now we'll switch to the demo part. So the use case we've chosen is a climate control proof of concept. So it's a control loop, a 20-millisecond control loop, driving a compressor for cold air.
We have a compressor and evaporator plant model, HMI to control the system. So it's a closed system for the demonstration. And we have applied the service-oriented architecture to this using a request/response method and some events and some console output to see something moving.
So the full model is this one. So it was a reuse of an existing one, for sure. And we have divided it on-- with three software components. One on the left is the HMI just to control on, off, and temperature set point. The middle one is a simple PID controller comparing the output temperature and driving the compressor current. And the plant model is a representation of the compressor.
So from the architecture point of view, it's a simple example. But it's done using the UML tool. So it represents, on the yellow boxes, the different interfaces. On the left, we have three events. And on the right, we have the request/response method. I will make a zoom on it.
So from this, we extract a Franca IDL definition automatically from the tool. And we translate. So we recognize the interface-- one method with one input and one output. Very simple. And we have translate it to Android IDL definition, just defining the interface and the method.
So in the MATLAB Simulink world, here is a representation. We have the three software components in this model communicating through a method interface-- so client/server. And the three events we are represented with messages in MATLAB Simulink.
And of course, the code generation is Embedded Coder C++. Very simple. And for the demo, we have make it run on a Google Cloud Workstation using Android Cuttlefish virtual machine with the Android Open Source Platform. I will launch the Android debug shell and launch the three application, communication-- communicating it together.
Here, I've shown five terms. On the left, I launch the virtual device. Once it is launched, I will connect to it on the four other terms by Android debug shell.
And then I will launch the three components, beginning on the left with the common one. So it's HMI just to control the on, off, and temperature set point. So now it's waiting for the service to connect. Then I launch the controller. We'll connect to the HMI and wait for the refrigerant loop. So it's a compressor. Then it is launched. Connecting.
And then it will loop. So the system is off. So no current. Zero. And the output temperature is 34 degrees, like yesterday at Stuttgart.
So I switch the system on. I'd like to have 25 degrees. So it's starting regulating by driving a current to the compressor. And the temperature is decreasing. And so it's a PID. So it makes a few minutes. That's the reason why normally I've made a shortcut. It will appear. Ah, yes.
And on the top right, I show the different services which are running to demonstrate that it runs all the services, Android services necessary for the three components to communicate. And after a few minutes, we can observe that it has converged to 25 degrees.
And then if I want to 23 degrees, and so on, it will continue the regulation. So that is how it is working on Android virtual machine-- so involving MATLAB Simulink models and communicating through Android binders.
So as a conclusion, we've shown here that MATLAB Simulink was able to model software components in a service-oriented architecture way, that the Embedded Coder C++ is easy to use, easy to connect to object-oriented remote procedure call, interprocess communication, like the one offered by Android.
So that was a bit manual. So the next step is to automate a bit of the process, first to be able to import in MATLAB Simulink the interface definition. So the usage of System Composer is a good way. We are trying it. And for the code generation, what would be perfect is to automate the main program, the glue code generation, beginning with the Android IDL and the model outputs. So that's it. Thank you for your attention.
[APPLAUSE]