between the ECU source code and the ASAM description files (e.g. *.a2l) generated for ASAP2 reading calibration and measurement systems.
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.
Note: Import/Reuse of existing data.
Existing data might be:
Input of definitions via the DDS editor
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.
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)
All steps (except the manual input) can be performed completely automated (in Command Line Mode)