If an existing function model has to be used in a new AUTOSAR project, the interaction described in the architecture-driven development noted in Part 1 can also be initiated from the function view. This function-driven development process is shown in the figure below. If the function is available in the form of a TargetLink® (a production code generator) model, it can be migrated by using the TargetLink AUTOSAR Module. The associated data dictionary is used to specify the attributes that each AUTOSAR software component (SWC) requires. When the model has been completed, TargetLink automatically generates a component description in the form of an AUTOSAR XML file, in addition to generating the AUTOSAR-compliant C code.
This description is imported into SystemDesk architecture design tool as a new software component. It can then be integrated into an overall system by linking it to other components. The interfaces can be checked for compatibility. If they are not compatible, for example, because deviating fixed-point scaling was used, the component developers have to adjust the interfaces. The RTE (Runtime Environment) cannot be generated until all software components are correctly connected.
The iterative nature of the procedure should be emphasized herewhen the software architect changes the SystemDesk model, he or she also creates new versions of the software component descriptions for the responsible developer. Parts that are different than the old data are indicated in the dSPACE Data Dictionary Manager. If a developer then creates a new version of the software component, the SystemDesk model can be updated without important information being lost. For example, the connections between the components and their properties are preserved.
Application and basic software
Software architecture according to AUTOSAR is subdivided into a platform-independent application layer and the platform-dependent layer of the basic software. The RTE is the generated mediation layer in the architecture.
The various requirements that apply to the software at different levels are reflected in the tools that are usually used for development. The software components in the application layer can be created on a model basis and automatically transformed into C code. For the basic software, libraries or generators are often used. Thus, data exchange between the development tools involved has to be defined in a specific project.
This process will be explained by means of the tools SystemDesk and EB tresos®. For software integration on a single ECU, all the elements required by the application, by the ECU hardware, and by the network, are put together for the selected ECU in SystemDesk.
The following steps have to be performed:
The AUTOSAR initiative is introducing new format standards in the development of ECU software. These standards allow reliable data exchange between the tools that support essential tasks within the design process, i.e., system design, function design, and configuration of the basic software, along with general tasks involved in process management and version handling. The tools presented here can process the AUTOSAR format standards and can be coupled seamlessly, thereby providing a range of tools for developing AUTOSAR-compliant ECU software.
Joachim Stroop is lead manager for System and Function Design Tools at dSPACE GmbH.