Automatically Generated Production Code
Handwritten code usually takes a long time to develop and nevertheless contains many errors. With the production code generator dSPACE TargetLink, unnecessary manual translation from model to code is avoided and concentration can be placed on more significant problems. The automatic generation of production code means that less testing in the target system is required, as compliance with a previously verified model is obtained. With TargetLink, efficient and optimized production code in C is generated directly from the Simulink® or Stateflow® model – in some cases also from the MATLAB® code – and simulation of the code takes place directly on the PC to verify that scaling effects, etc. does not affect functionality.
Optimization can be done automatically concerning, for example, execution time orThe code’s efficiency and execution time are kept just as good – or better – than with manual programming, which has been verified by several studies.
Back-to-back testing and verification
It is important to continuously test and verify your code from the very first line of code. Before the ECU hardware is even available, you can start testing your application code at different levels, commonly referred to as Model-In-the-Loop (MIL), Software-In-the-Loop (SIL), and Processor-In-the-Loop (PIL).
In MIL, the purely logical implementation is tested. Large float data types are used to get as close to the developer’s non-profit environment as possible. The simulation is used as a reference implementation and thus does not take into account quantization effects or similar problems.
The SIL simulation is done with TargetLink-generated production code in which primitive data types and possibly scalings are used, so that you can catch errors related to quantization, for example.
PIL finally tests directly against the target processor, usually in the form of a development card from the processor manufacturer. In this step, you also get any compiler bugs and performance problems that come from running the code directly on a microprocessor.
TargetLink enables the collection of measurements from all stages so that you can then compare your results in MIL, SIL, and PIL to ensure that the final code works as the developer intended. Performing the same tests in several steps and comparing their results in this way is called back-to-back testing.
The standard AUTomotive Open System ARchitecture (AUTOSAR) is available in two variants:
- Classic for classic, time-critical embedded control systems where the ECU software is statically configured for a specific hardware platform
- Adaptive for service-oriented software architectures with a greater focus on flexibility and the ability to update the ECU software afterward
dSPACE TargetLink can generate production code adapted for both AUTOSAR Classic and Adaptive.
dSPACE strategic partners Model Engineering Solutions GmbH (MES) are experts in quality assurance in model-based development and offer a range of tools to ensure that the model – and thus the generated production code – maintains high quality.
The model is used both as the documentation for the software and as a basis for generating the production code. Therefore, the model must follow accepted standards and guidelines, for example, ISO26262, DO 178B/C or MISRA ®, as well as company-specific guidelines.
To check that guidelines are followed in the development of Simulink® and TargetLink models, there is MES Model Examiner® (MXAM). MXAM is the market leader in guideline checking of Simulink® and TargetLink models.
Since the model is the documentation of the code, it should keep the complexity as low as possible. MES M-XRAY® (MXRAY) which can visualize the model’s architecture and recognize, for example, subsystem clones and provide a measure of complexity in different parts of the model.
In some cases, many measures are required to reduce the complexity of the model or to adapt it to new or existing guidelines. Many of these measures involve monotonous tasks such as moving signal flows through subsystem hierarchies and can instead be automated to facilitate work. Here, too, help is available, in the form of MES Model & Refactor® (MoRe). For example, MoRe can merge subsystems, add signals across multiple hierarchy levels simultaneously, or create bus structures.
The code never gets better than its specification. dSPACE strategic partner BTC Embedded Systems offers the tool Embedded Tester for automatic generation of test vectors for structural testing and verification of functional requirements. In a workflow according to ISO 26262, it is not only important with verification but also traceability. With the help of BTC’s Embedded Specifier, requirements are linked to tests in order to mechanically demonstrate that the result meets the requirements.
The complexity of large control systems is a major challenge for manufacturers and their suppliers. When functions are developed for a control unit (ECU) or a network of several control units, communication can be facilitated by formal system models. To meet this challenge, dSPACE has integrated a system architecture tool into its toolchain: SystemDesk.
SystemDesk has two main applications. As an architectural tool, broad and sophisticated support is offered for modeling systems according to AUTOSAR. A graphical interface gives the user an intuitive path into AUTOSAR’s complex world and reduces the risk of mistakes being made in larger projects.
The second main application is to create virtual control systems (V-ECUs) to be able to validate the control systems’ software, including any bus communication, early in the development process. The V-ECUs contain a production code for the functions to be tested, either with or without AUTOSAR Basic Software (machine components, such as drivers). These can then be tested on dSPACE simulation platforms, such as the PC-based platform VEOS.