Application Areas

SystemDesk lays the foundation for successful software-in-the-loop testing. Regardless of whether you are working with Classic AUTOSAR, Adaptive AUTOSAR, or without AUTOSAR (non-AUTOSAR), SystemDesk helps you create your system under test (SUT).

No matter your output data, SystemDesk supports you in creating a virtual ECU (V-EC). For example, you can import an existing Classic or Adaptive AUTOSAR architecture to use as a basis for configuring your basic software (BSW). In addition, you can use your fully integrated code directly with application software and basic software to create the V-ECU. Here, SystemDesk gives you countless options for perfectly tailoring and implementing your system under test according to your requirements. You can also follow the industry staple FMI standard and export V-ECUs as FMUs. This means you can execute the V-ECU at any time in VEOSor any other FMI-compatible simulation platform. This flexibility provides the perfect basis for your subsequent SIL and HIL tests.

Aside from importing an existing architecture, SystemDesk allows you to model your complete AUTOSAR software architecture. An advanced validation function guides you through the individual steps to ensure compliance with the schema. This architecture then forms the basis for implementing the software components and for the basic software configuration.

Creating a Valid and Realistic System Under Test (SUT) for SIL Testing

A V-ECU is ECU software that can be executed in a SIL environment. The V-ECU can be based on Classic AUTOSAR, non-AUTOSAR-compliant code, Adaptive AUTOSAR, or even POSIX applications. SystemDesk offers complete support for creating any type of V-ECU for SIL testing.

Interchangeability and sharing of V-ECUs is important to many of our customers. This is why SystemDesk lets you generate not only V-ECUs for the dSPACE SIL solutions but also standardized V-ECU FMUs. V-ECU FMUs are 100% FMI-compliant, do not use proprietary interfaces, and therefore offer maximum compatibility with numerous simulation platforms.

In the classic AUTOSAR context, a V-ECU can contain production code for the features to be tested, either only at the application level or including the basic software. The V-ECUs can be created including the application software and dSPACE basic software or with your own basic software. By using dSPACE basic software, you can create a V-ECU quickly and easily without extensive knowledge of AUTOSAR, whereas integrating your own basic software makes it possible for a realistic virtual ECU to simulate your real ECU. Non-AUTOSAR-compliant code can also be used as a basis for a classic V-ECU. This is done by entering functions, their cycle times, and interfaces. V-ECUs can even be created for non-AUTOSAR ECUs with basic software.

In addition to V-ECUs in the conventional context, V-ECUs can also be based on dynamic architectures. This includes both POSIX applications and Adaptive AUTOSAR. Adaptive AUTOSAR has a different architecture, in which a run-time environment is used independently of the application level, which is referred to as middleware. As a result, applications can be exchanged and updated flexibly while still using middleware features that were standardized by AUTOSAR. For the V-ECUs, you can use either your own middleware or the middleware from the AUTOSAR Adaptive Platform Demonstrator.

You can use VEOS to simulate the generated V-ECU, thus validating your software in a PC-based simulation. Of course, this also applies to Linux-based V-ECUs from the adaptive environment. Together with experiment software such as ControlDesk, you can evaluate the results.

Did you define a behavior in the software that you want to change? Simply load your software architecture in SystemDesk and change the necessary components or adjust the C code. After generating your V-ECU again, you can check the results of your changes directly with VEOS. Short paths to quick and valid results.

The Right V-ECU for Your Tests

On the way to the real ECU at the end of the development process, SystemDesk supports V-ECUs at the application, simulation BSW, and production BSW level.

Application Level V-ECUs

Application-level V-ECUs, which we also call level-1 V-ECUs, can be used to perform comprehensive functional testing on application software. Both individual software components and a complete application software can serve as the basis for the V-ECU. Even at this initial level, the V-ECU can be used within a continuous testing process to detect errors early on in the development process.

Simulation BSW V-ECUs

In addition to the first level, a level-2 V-ECU includes non-productive basic software that was created only for this specific V-ECU and its simulation. Thus, the V-ECU can be connected to a virtual bus and tested in a broader context.

Production BSW V-ECUs

In addition to the application software, production BSW V-ECUs also contain the productive basic software. This way, level-3 V-ECUs simulate the hardware-independent software of the real ECU. Because these V-ECUs are suited for complete ECU software tests, they are often used by ECU managers in HIL frontloading. 

Modeling Your Software Architecture

Create your own AUTOSAR software architecture from scratch or enhance an existing architecture.

SystemDesk offers comprehensive modeling tools. For example, you can create individual or multiple software components down to the last detail before combining them into an integrated composition. As a result, it is possible to model the entire application layer of an individual ECU or even application software spread out across multiple ECUs.

The modeling of a classic AUTOSAR architecture is supported in SystemDesk by intuitive preconfigured dialogs to maintain an overview of your model at all times. The comprehensive graphical support not only helps you use the product for the first time but also promotes efficient work with reduced errors in large-scale projects. 

In such large-scale projects, AUTOSAR files are usually stored centrally in a version control system, such as git, so that various developers and architects can work separately and in parallel. If any conflicts arise or if you simply want to obtain a quick overview of any changes, dSPACE AUTOSAR Compare supports you completely independently of your other tools. Combined with SystemDesk, you can even display the differences between a specific file and the current project state in SystemDesk.

To improve the quality of the projects, SystemDesk includes a function for the comprehensive, rule-based validation of consistency and correctness.You can validate both the entire architecture and individual components or elements from the dialogs.

To provide even more comfort, SystemDesk can help you automate recurring tasks. An advanced API allows for a high level of automation using simple Python scripts.

From the Starting Point to the Complete SIL World

You have created a V-ECU with SystemDesk based on your software architecture: this marks your start in the flexible and cost-effective world of software-in-the-loop simulation. Thanks to the scalability of a V-ECU, you can save valuable time spent on HIL testing, run different tests simultaneously, and even perform tests directly on the developer PC. Level-1 V-ECUs can even be used on SCALEXIO as a restbus.

In addition to the easy integration of SystemDesk into your existing tool chain, dSPACE offers compatible products for optimizing your workflow in the SIL world. For example, you can simulate one or more V-ECUs in VEOS and test them in a realistic environment. ControlDesk allows you to evaluate all of the values in a concise overview, while AutomationDesk allows you to run your tests completely automatically.

AUTOSAR files can be saved centrally to allow various developers and architects to access them in parallel from all of these products, in a version management system such as git, for example. If any conflicts arise or if you simply want to obtain a quick overview of changes, dSPACE AUTOSAR Compare supports you completely independently of your other tools.