Data Declaration System - DDS

The Visu-IT! Data Declaration System (DDS) represents a central repository for all ECU variable declarations and thereby ensures consistency between the ECU source code and the ASAM description files (e.g. *.a2l) generated for ASAP2 reading calibration and measurement systems.

DDS is primarily used by:

System engineers to specify project specific data structures together with calibration entity characteristics. This information can be reused by ECU software developers.

System engineers and ECU software development engineers for the definition of ECU related characteristics (such as calibration maps, axes and parameters) and online data (variables) as well as attributes related to software design (such as the mapping of entities to engineering units). Once the ECU calibration objects have been declared in a DDS project data pool, an IEEE-695 or ELF standard format file can be imported to map the required ECU memory address and size information to the calibration entities in this data pool. Following this memory address and size assignment, a description file of the DDS project can be exported for tuning and data acquisition in a calibration system reading ASAP2 (ASAM MCD 2 MC) files or in the SAM Application and Measurement System.

System engineers and Calibration engineers to define or modify the functional grouping and attributes of definitions (such as calibration limits or display formats) not related to ECU software design in order to make such information available in ASAP2 reading measurement and calibration systems such as INCA.

The following figure illustrates the important role of the Data Declaration System in this integrated development and verification environment.

The principal process flow is:

Import/Reuse of existing data.

Existing data might be:

ASAP2 (ASAM MCD 2 MC) files from suppliers/customers which should be merged to/with the current project in order to generate one global/valid ASAP2 file. In this scenario, DDS servers as a common data integrator. Note that by using the DDS component Compare/Merge, even ASAP2 files which overlapping/conflicting definitions can be imported into DDS in a controlled way.

Generic DDS Database Modules from a central library/department which should/must be reused for all projects. The generic components might get customized within the current project scope by modifying some global settings which are located outside the generic Database Modules.

Project specific DDS Database Modules from a previous project which should be reused. These modules might be modified/updated in the current project scope.

Customer specific files which should be imported into the DDS database, e.g. for migration purposes.

Data from a global data dictionary system. DDS will use these data as a basis and add additional information necessary, e.g. for the software development.

Input of definitions via the DDS editor

manual input via the graphical user interface

script based input by using the DDS COM-API

Source Code generation (ANSI-C)

Compilation & Link

Import of locator file (to get the physical addresses)

Description file generation (e.g. ASAM MCD 2 MC)

Re-import of calibration data (optional)

Note: All steps (except the manual input) can be performed completely automated (in Command Line Mode)