Accelerating Development of VCU Software in Iveco eDaily with Model-Based Design
Dr. Alessio Canepa, Head of Simulations and Controls, Electrification Technologies Department, Iveco Group
The eDaily is Iveco Group's new electric light commercial vehicle, launched in 2023. At its core, the vehicle control unit (VCU) represents its brain, working as the center of a sophisticated star-based control system. The VCU oversees various aspects of the vehicle such as traction control, thermal systems, recharging processes, the entire HV domain, HMI components, and more. To keep full control over the vehicle software, Iveco developed the VCU application software internally, establishing a dedicated team of software engineers and defining related processes, methods, and tools.
This presentation illustrates how Iveco Group choose an approach based on Model-Based Design leveraging MATLAB® products. By making use of libraries, data dictionaries, and referenced models, we designed a completely new software architecture to create a clear separation between the application software and the basic software, and to make the application software easily reusable over different projects. We reserved part of the software for safety monitors to achieve compliance with ISO 26262.
Safety-related software was qualified with Simulink Test™, Simulink Report Generator™, and Polyspace®. By integrating SVN into our Simulink® project, we designed a development process where multiple software engineers can work in parallel in an agile manner, achieving near-daily software releases. We created a virtual vehicle where our whole VCU application software can be integrated and tested. By using model variants, we made the virtual vehicle effortlessly convertible in the emulation engine of the hardware-in-the-loop testbench for our VCU. Finally, many of the actions needed to build and test the software have been automated via scripts to obtain an effective CI/CT pipeline.
Published: 3 Jun 2024
Thank you, everybody. It's nice to see you here. Let's jump to the agenda.
So I'll first give you a little bit of context about what is the eDaily and what is our software platform, eVECOP. Then we will talk about the software architecture that we use. Then we will deep dive into software components and how we use data dictionaries.
Then we will see how it works, our software development process. Then I will deep dive into verification and validation workflow that we use. And finally, I will give you some info about our continuous integration and continuous testing pipeline.
What is the eDaily? The eDaily is the electric version of the Daily, IVECO's leading light commercial vehicle. It has been launched in 2022. And among its features it has up to 400 kilometers of range with the one to three batteries configurable number.
It has up to 7.2 tons of gross vehicle weight, up to 3.5 tons of towing capacity, and up to 15 kilowatts of electric power take off. It also features a 100 kilowatt power e-motor. so it's a pretty powerful electric vehicle.
What is the VCU? The VCU, those that work on electric vehicles, they already know it's the Vehicle Control Unit. So it's the central brain of the vehicle. It works as the center of a star-based control system. Of course, for an OEM, it's very strategic to have ownership on the software of the vehicle control unit since it works as a brain.
In our case, the application software of the VCU is a software platform, actually. Not one single software, but a software platform that we call eVECOP, electrified vehicle control platform. Why a platform? Because it is used to control several different vehicle types. We use it to control light commercial vehicles, medium, heavy, and also buses.
So it is easily reusable over several projects. And we do have roughly 90 functions implemented on it. Functions are traction control, regenerative braking, high-voltage safety, electric power takeoff management, recharge control, and whatsoever. And we are here because 90% of this software is designed in model-based design.
Let's give a look at the high-level architecture of our software. So we do have, at the bottom, the hardware and basic software. This is not the part that we do. We do have a partnership with Bosch for this.
So they provide not only the hardware, but also the basic software then in AUTOSAR. And then we put on top of it our eVECOP platform. The big part of the platform is the application software, the green part. Then we have a middleware which works as a kind of glue between the application software done in model-based design in Simulink, to the APIs that the basic software of Bosch provide us. Then, of course, we have some processes and tools that help designing software very quickly, for example, automation scripts and so on.
Going inside the application software, what do we have? We have like everybody, we do have software components or software modules. I want to here show you in detail how we treat them. With reference to MathWorks' technology, we use model references.
So we have one big Simulink model which represents our complete application software. And inside this one, we do have all the single software components treated as model references. Working in this way is very useful because each single software component is a very autonomous entity. So you can use MathWorks tools such as Simulink Check, Simulink Design Verifier, Simulink Test, in a very context, independent way. You can take the software component and analyze it apart from the rest of the software.
Then, of course, we use a standard. Here, it's an example to integrate all these software components together. But the message is that using standards, even your own standard, is extremely important because it helps you automating the way these software components can be brought all together. For example, here we very simply use buses to put together all the outputs of one single software component and make them available to the others.
When we go inside the software component, how is it done? A software component very easily for us, it's a folder inside a Simulink project. So we do use a Simulink project because it helps us automating the way each subfolder is included in the MATLAB path. Moreover, using a Simulink project helps us with the integration with the software versioning tools.
Also very graphically, as you can see in the image, you can see in this case, we are using SVN. You can see if there are some files that have been changed, some that are not committed yet, and so on. And, of course, it also helps a lot with the dependency tracking. Whenever you modify a file, whenever you delete a file, it informs you in case of any dependency.
Going inside the folder, we do have subfolders for documents of that software component, for requirements, for tests. And the two most important files are the last two-- the data dictionary, we will talk about it later, and then the model itself, which contains the logic of that software component. You can see that we use a very clear naming convention, which is fundamental to keep the software organized.
Data dictionary, for those of you who don't know data dictionaries, these are really useful. It's like a file which contains data relevant for a Simulink model. So inside the data dictionaries, we have parameters, signals, enumerations, and lookup tables for each software component.
And for these inside the data dictionary, we can specify things such as a description of that variable, because in the end most of them are variables, descriptions, minimum, maximum. We can set code generation options. For example, I want this variable to be declared exactly in this file. And this helps a lot.
And also, all this data is then put into the so-called A to L file, which is then read by calibration tools whenever you go on the vehicle. So you see very graphically in a very nice way, for example, lookup tables or enumerations. And also the description of the variables automatically goes there without any effort.
Let's give now a look at our software development process. It's a pretty standard development process for the component, for the VCU component. So we start from software requirements at component level. Then our software architect splits these requirements into requirements for each single software component. So model-based design developers take these requirements and they implement it into models. And, of course, then these developers can perform their own modeling the loop tests alone.
Then it comes the software integrator, who's the guy or the script that puts together all these software components into the big model altogether. And at this stage, we have the green block, which is a virtual complete VCU. And it's very important this because we can run virtual vehicle tests. We will see about it later.
Then we run with the embedded coder, we generate the C code. And finally, we integrate this C code with other C code, a C code which comes from the supplier, for example, of the basic software and from changes to the middleware, for example, configurations in the operative system. Finally, we build. And we obtain many files among which the hex file and the map file.
At this stage, we are ready for hardware in the loop and vehicle tests. This is an overview. We will then go into the details of our verification and validation workflow.
So we start from doing verification and validation at single software component level. Then we put all the components together and we generate this virtual complete virtual VCU that we integrate in a complete virtual, vehicle model. Then we go on the hardware in the loop. And then finally on the real vehicle to perform vehicle validation.
Let's see this a little bit more in details. So a huge part of our verification and validation workflow is done at model level. We use a lot of Simulink test. We create test harnesses around each software component.
There are several methods to test single models inside Simulink. We use Signal Editor a lot to have full control over our input signal that we use to stimulate the software component under test. We can also reuse data coming from real world, collected on the vehicle, and then we can put them here to see what's the behavior of the software component.
Then to assess the results, we use logical and temporal assessment to quickly verify the responses to triggers. This is used a lot for functional safety, for example. And then we use the test assessment block, which is necessary in case of more complex test cases, let's say.
Simulink Coverage is extremely important because just having a test result OK is not enough. You need to be sure that the coverage that you reach is very high. And so we use this tool to be sure that we are reaching high level of coverage. Of course, the coverage you reach depends a lot on the coverage metric. For example, MCDC is one of the most used.
Then still at software component test level, we use a lot of Simulink Check. This helps us to verify the compliance of the model with the modeling guidelines. So for example, with the ISO-26262.
And finally, we do some checks with the Simulink Design Verifier, which is maybe the tool that I like the most. Simulink Design Verifier is able to detect the design issues such as dead logics. But the thing that I like the most is that it can automatically generate test cases that stimulate your software component so that you reach 100% coverage. So reaching 100% coverage when you have a complex model is not easy doing manual tests. This automatically can generate the test cases that test all the possible execution paths of your model.
At the end of the process, we use a Simulink Report Generator to generate a comprehensive report of what we got from these tests. Virtual vehicle, as I said before, this is something we are investing a lot. So it's a virtual vehicle with the physics of the system and all the electrics and electronics of the system.
So also the single wires of the vehicle are replicated here. We use the Simscape library for physics, thermal, mechanics, electrics, both high voltage and low voltage. And it's important to understand that the VCU logics here inside are the real ones. We copy and paste the VCU logics inside of this virtual vehicle. All the other components are virtual VCUs that we recreate from components, from input, from suppliers, and so on.
Our idea is to perform here the vast majority of the software validation. Advantages that we have working this way is that we don't need any physical hardware. And we can replicate this into the laptops of each single software developer.
So they can alone, like when you work with Android and you have Android emulators, they can alone test not only the software components, but also the integration of these software component with all the others. This definitely helps a lot. And, of course, since this is fully virtual, it can be part of a built, fully-automated pipeline that can run, for example, on a cloud server.
This is just an example of how the virtual vehicle works. It's like a super small video game. And but the important thing is that behind this, you have all the software components. And you can actually press pause and go inside, put breakpoints, and see whatever what is happening behind the scenes.
Hardware in the loop, you know how hardware in the loop works. Here, I just want to mention that working in this way, since in the hardware in the loop you need, however, a virtual model of the vehicle that emulates the vehicle, in this way you can actually develop only once the virtual vehicle and then when you are on the virtual vehicle side, so on the left, the logics of the VCU are a model, copied and pasted, the green one.
When you are on the hardware in the loop, you use model variant to switch this block into a block which is empty and connects with the external hardware. In this case, you can also completely recycle the test cases that you implement here because they can run also on the other side, just the device is physical.
Last topic, the CI/CT pipeline-- Continuous Integration, Continuous Testing. So what does this mean? This means trying to get to a point where with just one click, you perform automatically the integration of all the software components together. Also, every time you have an update. And you test them automatically. And you build the software.
It's important also to mention that, as I said before, since it is not only a continuous integration, but also a continuous testing pipeline, also tests are automated. So the model in the loop test that I said before can be automated here. Virtual vehicle testers can also be automated, but now I left them outside because we are not yet there. Hardware in the loop, technically you can automate also them. But I'm not considering them as part of our continuous integration, continuous testing pipeline.
This is how it works a little bit more in detail. So our CI/CT tool is Azure pipeline from the Azure DevOps platform. So inside this platform, we do have Git as a repository. And so the platform is configured in this way. Whenever a software developer does a commit, so an update of a software component, automatically Azure pipelines triggers a set of jobs or tasks.
And these tasks, in the end, are nothing else than calls to MATLAB's scripts. So you can have your own MATLAB script designed in MATLAB, fully MATLAB, that calls a series of tasks that you have already designed, for example, in Simulink test for each software component. And very simply, this script will be automatically called by the Azure pipeline.
One very nice thing is that test results are automatically given out by The MathWorks' Toolchain in XML format that is compatible with the Azure pipeline. So with no effort, the Azure pipeline can read out the test results and in a very nice, graphical way, show you the result of all these tests.
Of course, the Azure pipeline can also call other scripts that not only run the tests, but that also call the full build of the software or code generation, I'm sorry. In our case, the code generation happens inside MATLAB, while the overall build of the software to get the final executable happens outside MATLAB. But, of course, the Azure pipeline can also trigger some powershell scripts that, outside MATLAB, they call the software build.
And that's it from my side. I just want to recap some key takeaways. So the first one is that the application software of the VCU of the eDaily is completely designed in model-based design. The second one is that software components are tested via combination of Simulink Check, Simulink Design Verifier, Simulink Test, and Simulink Coverage.
The software components are integrated at Simulink level, thus obtaining the very important virtual VCU model. Four, a virtual vehicle is used to find and fix, I think more or less, 80% of the software integration issues. Then model variants are used to easily switch between virtual vehicle and hardware in the loop tests.
And finally, we use a CI/CT pipeline to accelerate the software integration and testing activities. That's all from my side. Thank you for joining.
[APPLAUSE]