08.10.2014 08:10 |
Virtualized ECU (s)
For the successful implementation of vehicle functions in electronic control devices, a variety of methods for the design and protection available, which have been introduced in recent years. These include in particular the model-based design and model-based verification of individual vehicle functions. Due to the AUTOSAR standard and it describes software architecture is also providing additional opportunities not only perform early verification of individual components but also to validate the entire application software control of multiple devices in conjunction with the early basic software arise. Virtualization lets already detailed without real control unit hardware and extensive tests run
Tried and tested:. Based Development
Virtualized ECU (s) and AUTOSAR (Photo: dSPACE)
The development of individual AUTOSAR software components (SWC) comes through the established techniques of model-based design for several years successfully used. De facto fit AUTOSAR-compliant development and model-based design very well together, because models can be used as single-source not only for the generation of the actual component codes but also for the generation of other artifacts, such as the required AUTOSAR-exchange formats.
Figure 1: Exchange specifications between architecture and behavior modeling and integration of AUTOSAR software in a virtual ECU. (Photo: dSPACE)
In practice, the managers sat mostly on one architecture-driven top-down approach to component development. In this case (Figure 1 above), the definition of the interfaces of a component in a pre-AUTOSAR architecture tool as SystemDesk dSPACE, the component developer must then implement against these interfaces. The approach is especially attractive because the interface specifications are directly usable for generating an AUTOSAR frame model that contains the required ports already. Thus, it is automatically guaranteed that the Komponentenmodellierer against the predefined interfaces implemented and that the components can easily be integrated later. The desired algorithmic functionality can then be easily inserted into the AUTOSAR frame model. As a result, created in a short time a first design of the AUTOSAR software component that can be generated for the immediately AUTOSAR-compliant code. By the described approach the component developer need not be a real AUTOSAR expert; it can be rather (all) focus on its respective subject domain.
Figure 2: Model-Based Design of AUTOSAR software components with TargetLink. (Photo: dSPACE)
Figure 2 shows how a possible model-based design of an AUTOSAR software component represents in Simulink / TargetLink. In the production code generator TargetLink, dSPACE support the AUTOSAR is anchored natively, which is reflected for example in explicit AUTOSAR AUTOSAR optimizations for highly efficient code. Special AUTOSAR block dialogs are used for visualization and editing of AUTOSAR specifications that are stored for the purpose of better exchange with AUTOSAR authoring tools in a data dictionary. This approach supports AUTOSAR-engineering round-trips as well as dealing with changes particularly well, since different data sets compared, merged and can be synchronized with a specific AUTOSAR model.
Model-based testing for individual SWCs
For many years, model-based unit tests are successful for verification of automotive software series. Fundamental to this are the concepts of the MIL (Model-in-the-loop), SIL (Software-in-the-loop) and PIL simulation (Processor-in-the-loop), which tests directly in the Simulink / Target Link-environment take place. The test cases can this be both on the actual block diagram (MIL) as well as on the host PC (SIL) or an evaluation board with the target processor (PIL) and, in so-called back-to-back tests on differences Checked .
Virtual Development
The existing concepts and methods can be applied almost entirely to the individual test AUTOSAR software-components. To take into account is simply that the verification of component codes individual files of RTE (Runtime Environment) are required to allow the build process for SIL / PIL tests. TargetLink supports this, the generation of a stub or simulation RTE, what core functionalities of SystemDesk used. The case generated for the component object files are then executed in SIL and PIL testing. TargetLink supports the generation of object files in the so-called AUTOSAR Compatibility mode, which software components can be passed not only as source code but also as object code files, what is relevant in particular from IP protection reasons . The determination of coverage metrics for the generated code (code coverage), as prescribed by ISO 26262 for safety-critical components, can be carry out under the SIL / PIL simulation. It is advisable, TargetLink in connection with special test tools such as the BTC Embedded testers to use to create test cases efficiently and to determine the appropriate coverage metrics. Overall, way ahead of any testing activities for a single isolated AUTOSAR software component fully implement virtualized in the Simulink / TargetLink environment without having a real copy of a control device is present.
Virtual ECUs for the earliest possible verification of software
The AUTOSAR standard provides with its well-defined software interfaces and standardized architecture, the basis for early virtual hedging arrangements of the software, which may have a high degree of realism. This is particularly advantageous because just in new developments hardware prototypes are often not available at the beginning. The validation and testing of the software are then carried out by performing a so-called virtual ECUs (V ECUs) with a high level of detail without the real hardware.
A virtual controller is generally understood as software in a simulation scenario (real-time or simulation time) emulates a real ECU, with the detail of emulation in detail can be seen differently. An advantage of this approach is not only in the early validation, but also in the fact that late availability of real control unit hardware the possibility of directly reuse many previously developed artifacts such as test procedures.
A virtual AUTOSAR ECU in particular contains the following software components (Figure 1 below).
- The actual application software in the form of AUTOSAR components, either in their entirety or a selected subset of these
- A generated for the virtual controller RTE to implement communication between application components and basic software and instantiate operating system tasks.
- hardware-independent base software components, such as an AUTOSAR operating system as well as individual AUTOSAR Services, for example, for the NVRAM management.
Overall, the virtual AUTOSAR ECU is following the layer model of the AUTOSAR software architecture to emulate the software on the real controller as realistically as possible can.
create virtual AUTOSAR ECUs
The generation of virtual controllers in the AUTOSAR tool chain from dSPACE is performed using the architecture and integration tool SystemDesk (Figure 1 below). For this purpose, the user specifies an ECU including the application components thereon, RTE and configured operating system and can create a virtual AUTOSAR ECU then by SystemDesk. For a simple simulation VFB (VFB: Virtual Functional Bus), it is possible to create the configuration of the RTE and ECU essentially by a directed flow of SystemDesk click of a button. This is because at the VFB simulation the interaction of software components of the application layer is in the foreground, which is completely abstracted from the concrete ECU and network configuration. The Shares to be emulated based software for AUTOSAR Services automatically adds the required system when building the virtual ECU. However, should be a simulation of concrete ECU and bus systems, then a user can make the necessary configurations and let it create a virtual ECU by SystemDesk.
Figure 3: Running virtual ECUs in VEOS using ControlDesk. (Photo: dSPACE)
As a prerequisite for the generation of virtual ECUs must present to integrate AUTOSAR SWCs. In SystemDesk as an author tool such components can be created or imported based on the AUTOSAR-exchange format. This allows to integrate software components of many different types, be they handwritten, created with third-party tools or model-based development with TargetLink. The latter is particularly convenient because TargetLink required for the exchange AUTOSAR files automatically mitgeneriert next to the component code and these can be summarized in the form of a SWC container for simplified transparent workflows. Principle can also create directly with Simulink or TargetLink function and software developers who are responsible only for individual components, V ECUs. The result is a simple V-ECU, which comes either for distance models for use or consists only of individual components of the application layer. For the complex networked interaction of a number of components of a virtual AUTOSAR ECU but should be generated from SystemDesk.
run virtual ECUs
New, innovative vehicle functions spread often over several different control devices and must be secured with numerous simulation runs, before they can be implemented in a vehicle. Therefore, a powerful simulation environment is required, which may take into account one or more virtual controls, including the data transmission between these ECUs. The simulation environment must replicate the hardware-dependent components of the control unit and have their own build functionality to make the virtual controller for each platform executable.
For PC-based offline simulation dSPACE provides the simulation platform VEOS that allows early development phases when no hardware prototype of the control unit is still available, a simulation of individual or networked virtual ECUs. VEOS particular also simplifies dynamic studies using standard tools from dSPACE as ControlDesk Next Generation Simulation control, recording and visualization of signals and the parameters of each calibration values (Figure 3).
The ECU software can be stimulated in open-loop simulations or test in closed-loop simulations in conjunction with plant models, the managers can not only consider single virtual control devices but a complete composite. The concept of virtual controllers provides for HIL simulation additional simplifications and opportunities. Thus, layouts, test procedures, and other artifacts from the offline simulation with VEOS let hardware-in-the-loop simulation reuse in later. Furthermore, the possibility exists alone or in combination to perform virtual controllers with real ECUs in the HIL simulation with SCALEXIO dSPACE.
In the manner described will find the new technologies of virtual validation through V ECUs catchment in existing verification and test processes for ECU software. dSPACE is this integration further advance – with an emphasis on the reuse of existing hardware, software and models
.
No comments:
Post a Comment