Standardizing data interchanges among design tools in the ECU development process: Pt. 1 - Models, formats, and data management

This article focuses on the question of what role these architecture-oriented tools play in the development process—for example, how they interact with tools for creating function models and how they integrate into various version control systems.

Introduction
With considerable commitment from numerous companies in the automotive industry, the AUTOSAR initiative has set out to pioneer a whole new basis for developing ECU software. The aim is to make software development much more efficient and flexible by using a standardized software architecture and standard data interchange formats for formal system models and for configuration data. The results of standardization work have now achieved high maturity, and further activities are planned.

At the same time, development tools that support the AUTOSAR standards and the proposed development methods are already available. These include SystemDesk and the AUTOSAR extension to TargetLink® the production code generator from dSPACE, and the configuration tool tresos® from Elektrobit (EB). These tools are already being used in industry's AUTOSAR projects. Experience gathered from these projects and further developments to the AUTOSAR standards will be worked into future versions of the tools.

Data interchange formats
The first projects reveal the broad outlines of application areas for these tools, which are largely determined by the tasks the tools have to support in the development process. The data interchange formats defined by AUTOSAR play a decisive role. The formats are defined by an XML-based scheme that allows fine-grained distribution in small units. These units can be saved to a file, either separately or in conjunction with other elements. The precise combination of data to be exchanged during development work can be specially adapted to specific tasks.

Flexible grouping and incremental refinement are also possible. A partial description of a single software component according to the AUTOSAR standard can be regarded as an initial specification; a function developer then completes it and converts it into an implementation. The structure of the underlying XML scheme and the referencing mechanisms have been specially designed for such use.

This feature discusses the potential uses of data interchange in an AUTOSAR tool chain by means of selected examples.

The tools
The potential applications discussed use the SystemDesk architecture tool as a starting point. SystemDesk now gives architecture-level and system-level support to graphical modeling, a familiar and well established method in function design. Thus, SystemDesk introduces a model-based development process very early on at system level, thereby supporting the AUTOSAR standard.

The main features of the tool are:

Simulation support at system level

Management of AUTOSAR data
The figure below shows SystemDesk's project view in the Project Manager on the left side. This view presents all the data that is managed by the tool that a user can use in the selected project. This project tree can be used to import and export AUTOSAR data. Typically, however, this option is restricted to specific elements in the tree, and in some cases to the elements linked to them: For example, to all the data types from the library or the structural description of individual software components. Further standards can be read into this project tree in the same way, for instance, a CAN matrix in the form of a DBC file. This screenshot contains an example of project library contents—with interface descriptions, data types, scaling of data types, and also software components.

View a full-size image

An orthogonal view of the project tree can be defined in SystemDesk's Package Manager, as shown in the right-hand part of the above figure. This area can be used to group elements from the project tree according to specific application cases or responsibilities. For example, a vehicle manufacturer can collect together and export all the data that needs to be transferred to a specific supplier for further processing.

In the other direction, library elements from a central point within the company can be imported via the Package Manager. The data can be grouped hierarchically in the Package Manager. The second lowest hierarchy level, also called a package group, corresponds to a single file in the system that contains all the data of the package group.

Connection to a version control system can also be implemented via the Package Manager. First, the version control system must be registered in SystemDesk, along with the necessary settings such as those for the local "sandbox." Next, the contents of a package group can be inserted in the version control system via the universal interface according to the SCC standard. In the version control system, these contents can be made available to other members of a project team. The usual version management functions are available in the context menu for a package group, and include loading the current version from the version control system to import it into the SystemDesk project.

Next: Interaction between system and function models

  <   

1 of 2

   >