This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Davinci (TL102A)

Davinci (TL102A)

Component Documentation

Specific Component Tools

1 - TL102A_Davinci Peer Review Checklists


Overview

Summary Sheet
Synergy Project


Sheet 1: Summary Sheet
























Rev 1.28-Jun-15

Peer Review Summary Sheet


























Synergy Project Name:


kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. TL102A_Davinci
Revision / Baseline:


kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. TL102A_Davinci_3.11.16.1_0

























Change Owner:


kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling
Work CR ID:


EA4#3190





























kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:















































































































































































kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:






















































Reviewed:































N/AMDD


N/ASource Code


N/APolySpace









































N/AIntegration Manual


N/ADavinci Files








































































Comments:

3rd Party Tool component. Only reviewed 3rd party files for correctness to installation and any Nexteer created






source files and documentation



















































































General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.





















Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)



















































Quality Check Items:




































Rationale is required for all answers of No










New baseline version name from Summary Sheet follows








Yes
Comments:

Follows convention created for
naming convention











tool components
























Project contains necessary subprojects








N/A
Comments:










































Project contains the correct version of subprojects








N/A
Comments:










































Design subproject is correct version








N/A
Comments:











































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/20/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































2 - about

About

About This Content

June 28, 2007

License

The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.

If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor's license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.

Third Party Content

The Content includes items that have been sourced from third parties as set out below. If you did not receive this Content directly from the Eclipse Foundation, the following is provided for informational purposes only, and you should look to the Redistributor’s license for terms and conditions of use.

Flute 1.3

The plug-in is accompanied by software developed by W3C at http://www.w3.org/Style/CSS/SAC/. Flute 1.3 ("Flute") is included with the plug-in without modification in lib/flute.jar. Your use of Flute is subject to the terms and conditions of the W3C Software License ("W3CSL"). A copy of the W3CSL can be found in about_files/copyright-software-20021231.htm and is also available at http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231. Source code for Flute is available at http://www.w3.org/Style/CSS/SAC/.

3 - about

About

About This Content

June 5, 2006

License

The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.

If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor’s license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.

4 - about

About

About This Content

June 28, 2007

License

The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.

If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor's license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.

5 - about

About

About This Content

June 2, 2006

License

The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.

If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor's license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.

6 - AN-ISC-8-1102_IdentityManager_MultipleECUs

Identity Manager - Multiple ECUs

8 - AN-ISC-8-1102_IdentityManager_MultipleECUss


 
Identity Manager - Multiple ECUs 
Version 1.6 
2010-09-09 
Application Note  AN-ISC-8-1102 
 
 
 
Author(s) 
Christian Weber, Hannes Futter, Marco Wierer 
Restrictions Customer 
confidential - Vector decides 
Abstract 
Configuration of Multiple ECUs with Vector's AUTOSAR BSW stack. 
 
 
Table of Contents 
 
1.0 
Overview ..........................................................................................................................................................1 
1.1 
What is the “Identity Manager” about? ..........................................................................................................2 
1.1.1 
Physical Multiple ECU ................................................................................................................................2 
1.1.2 
Multiple Configurations ECU.......................................................................................................................3 
1.1.3 
(Virtual Multiple ECU) .................................................................................................................................3 
1.2 
Operation principle of Physical Multiple ECUs..............................................................................................3 
2.0 
Configuring a Multiple ECU .............................................................................................................................4 
2.1 
ECUC creation (without overlay)...................................................................................................................4 
2.1.1 
What happens in the ECUC?......................................................................................................................5 
2.2 
ECUC Creation (with overlay) .......................................................................................................................6 
2.3 
Overlay Control File.......................................................................................................................................7 
2.3.4 
Signal overlay .............................................................................................................................................8 
2.3.5 
Splitting the direction of PDUs ....................................................................................................................9 
2.3.6 
Example ......................................................................................................................................................9 
2.4 
ECUC creation using DaVinci Project Assistant .........................................................................................11 
2.5 
Generating the RTE of a Multiple ECU .......................................................................................................11 
3.0 
Initialization of the BSW .................................................................................................................................11 
3.1 
Creation of the logic for identity selection ...................................................................................................12 
3.2 
Prepare the ECUM configuration ................................................................................................................13 
3.3 
Provide an user defined ECUM initialization function .................................................................................13 
3.4 
Where do I find the initialization structures? ...............................................................................................15 
3.5 
Overview of BSW module initialization........................................................................................................15 
4.0 
Diagnostics and Multiple ECU Support..........................................................................................................16 
5.0 
Supported use cases .....................................................................................................................................16 
6.0 
Restrictions and limitations ............................................................................................................................16 
7.0 
Additional resources ......................................................................................................................................17 
8.0 
Contacts.........................................................................................................................................................18 
 
 
 
1.0 Overview 
This application note explains how to configure and use the “Multiple ECUs” feature in Vector AUTOSAR stacks. 
 1  
Copyright © 2010 - Vector Informatik GmbH 
Contact Information:   www.vector.com  or +49-711-80 670-0 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
1.1  What is the “Identity Manager” about? 
With the Identity Manager ECUs can be configured to run in different scenarios without major changes1 in the 
software. The functionality provided by the Identity Manager is not covered by AUTOSAR explicitly. The use cases 
are:  
•  Physical Multiple ECU 
•  Multiple Configurations ECU 
•  (Virtual Multiple ECU) 
 
This document explains about how to use the Physical Multiple ECU feature. 
1.1.1 Physical 
Multiple 
ECU 
This aspect covers an ECU within a specific car line of an OEM. If there are several (>1) almost identical instances 
of this ECU which are connected to the same vehicle network at the same time, they are called “Physical Multiple” 
ECUs or “Multiple ECUs” in short. 
Examples: Door Module (DM), Seat Module (SEAT), Adaptive Damping System (ADS) … 
In this application note, we’ll use the Door Modules with the following instances as an example: 
•  Front Right DM_FR 
•  Front Left DM_FL 
•  Rear Right DM_RR 
•  Rear Left DM_RL 
 
The physical control units are derived from a common class with respect to the functionality. Hence, all control unit 
instances derived from this class potentially support the same superset of the functional scope. The actual ECU 
instances will be configured according to the position they will have in the network topology when they are built into 
the car. 
 According to the configuration there may be  
•  A different functional scope 
o  E.g. different MMI (man machine interface) for each ECU instance: Mirror control or special window 
control for all windows only on the Front Left Door Module, not on the other modules (application 
dependent, not covered by this application note) 
•  Different communication properties of the instances: 
o  Own NM message to transmit 
o  Own signals to transmit and to receive 
o  Own messages to receive and to transmit 
 
The System Description of the OEM contains the instances of such Physical Multiple ECU. For each instance, the 
OEM creates a separate ECU Extract of System Description. This set of ECU Extracts is the configuration input of 
the Physical Multiple ECU. 
                                                           
1 no major changes means: No changes in the application, but there are changes in the initialization sequence of 
the basic software which are not covered by AUTOSAR 
 
2 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
1.1.2  Multiple Configurations ECU 
Across multiple car lines of an OEM, the communication behavior considerably differs. However, the Multiple 
Configurations ECU is shared among an OEM’s car lines. Therefore there must be a mechanism for the adaptation 
of this ECU to different environments, i.e. different car lines. 
Note: 
Multiple Configurations ECUs are currently not supported. 
1.1.3  (Virtual Multiple ECU) 
Virtual Multiple ECUs are control units which are only virtually separate ECUs from a logical point of view but 
residing inside one ECU hardware board. An example for this is a combined radio / gateway control unit. 
Note: 
Virtual Multiple ECUs are currently not supported. 
1.2  Operation principle of Physical Multiple ECUs 
DataEl
taE ements = Sy
= S stem 
em Signals
PDU overlay
rla
RTE fan out
Rte
Superset DataElements
Merged D
ed ataEl
taE ements
e
DataElemen
em
ts
Merged 
ISIGs
ISIGs
Com
IPDU
IPDU
IPDU
IPDU
IPDU
PduR
Decision: 
sion
IPDU Æ
DU 
LPDU
CanI
Can f
Can
id1
id2
id1
id2
id1
id2
identity1
identity2
identity1
identity2
identity1
identity2
 
Figure 1 – Overview of the Multiple ECU feature, Tx path shown only. 
 
In Figure 1, you see an example of the operation principle of a Multiple ECU. Here, the Tx path is shown. The 
leftmost column displays what happens if you have to configure a Multiple ECU sending out different CAN 
messages and cannot use any kind of optimization because the signals for each identity are different. For each set 
of signals which have to be sent, a separate PDU is created and mapped to a corresponding CAN frame which is 
actually sent out. This situation also applies if you have a PDU which is transmitted in one identity and received via 
a different identity. Then, despite having the same signals on application level, two PDUs are created, one for 
transmission in identity1, a second PDU for reception in identity2. 
However, if you have semantically equivalent signals sent in different CAN messages, there is room for 
optimization. This is shown in the middle column. Semantically equivalent signals can be merged into one common 
PDU, the transmission is done in different CAN frames, but their content is equal.  
 
3 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
If the signal layout is not equivalent over the identities, this optimization is not possible (right column of Figure 1)
Therefore separate PDUs have to be used. Additionally: There may be only one signal on system level which is 
sent in different PDUs as shown in the rightmost column. In this case the RTE provides the fan-out to the Com. 
Vectors implementation of the Multiple ECU feature incorporates overlaying of PDUs as well as RTE fan in/out 
(signal overlay). 
2.0  Configuring a Multiple ECU 
Before you start with the BSW configuration, you have to create a valid initial active ECU configuration based on a 
collection of all required ECU Extracts of System Configuration. Additionally, the required startup mechanisms in 
the ECUM have to be provided. The State Manager has to recognize which identity is currently active and has to 
decide which initialization sequence it has to select for the current identity. Finally, the BSW can be configured 
based on this ECUC file. 
The PDUR controls the communication behavior in each instance of a Multiple ECU configuration. The PDUR 
implements the reception and transmission behavior as well as the mapping of CANIF PDUs (N-PDUs) to the COM 
PDUs (I-PDUs). If there is no optimization, the transmission and reception behavior is implemented over a 
superset of Rx and Tx messages in the CANIF. According to the active identity, the message is either transmitted 
or received or nothing of this.  
For the straight forward case, this can be reached by creating different PDUs for each identity. In an optimized 
case, the memory consumption can be reduced by merging redundant PDUs. 
2.1  ECUC creation (without overlay) 
For each ECU identity, the InitialEcuC generator reads in one ECU Extract of System description – see the figure 
below for an overview of the tool flow: 
 
ECU Extract
of System
Configuration
Description #1
ECU Extract
of System
Configuration
Initial ECUC
ECUC File
Description #2
Generator
.
.
ECU Extract
of System
Configuration
Description #n
 
Figure 2 – Creating an ECUC file from Multiple ECU Extracts 
 
4 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
In our example, we have the Door Module ECU with 4 physical Multiple ECUs. 
That means the OEM will provide four different ECU Extracts of System Configuration Description: 
• DM_FL.arxml 
 
• DM_FR.arxml 
 
• DM_RL.arxml 
 
• DM_RR.arxml 
 
The InitialEcuC generator is able to merge these extracts in one ECUC file which provide the superset for the BSW 
configuration. 
Tool usage: 
GenTool_CsAsrInitialEcuC.exe [–p <PrjName>] –m <EcuExtractOfSd1>…<EcuExtractOfSdN> 
Hint: 
The optional parameter –p <PrjName> gives the name of the resulting configuration/project. The 
name of the resulting configuration and/or project is the first file name given to the generator tool if 
no – p <PrjName> option is given. In our example, the PrjName = DM_FRL. 
Open a command line prompt and enter: 
GenTool_CsAsrInitialEcuC.exe –p DM_FRL -m DM_FL.arxml DM_FR.arxml DM_RL.arxml 
DM_RR.arxml 
 
A result of the generator run will be: 
DM_FRL.ecuc.arxml (active configuration – this one will be iteratively changed during BSW configuration phase 
and enhanced by vendor-specific attributes) 
DM_FRL.Initial.ecuc.arxml (initial configuration holding the basic pre-configuration for the BSW) 
DM_FRL.ecuc.vdsxml (this is a file which you can load with GENy; it references initial and active configuration. 
DM_FRL.Error.txt (describing errors encountered during the conversion) 
 
Note: The 
GenTool_CsAsrInitialEcuCMultConfMerge.dll must reside in the same directory like 
the ECUC generator dll (GenTool_CsAsrInitialEcuCDsIf.dll). 
2.1.1  What happens in the ECUC? 
The ECUC loader creates one network node per identity. Further, it creates a message/PDU list with references to 
the network node. 
The used set of PDUs or signals is a superset of the used PDUs or signals (unique names without duplicates). 
For each identity it creates a so called multiple configuration container in the ECUC file below all basic software 
modules for which a multiple configuration container is defined in their BSWMD files. The multiple configuration 
container incorporates the ECU name as identification. The container for the ECUM holds references to the init 
structures of the modules.  
The name of the multiple configuration container is composed of  
<name of the structure in the bswmd/paramdef file>_<EcuShortName> 
The EcuShortName is taken from the ECU Extract of System Configuration. In the door module example, 
ECU short name for the respective multiple configuration containers will be DM_FL, DM_FR, DM_RR, DM_RL. 
 
5 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
2.2  ECUC Creation (with overlay) 
Multiple ECUs typically have some messages that have the same signal layout and contain semantically equal 
signals (only with different names) shared at least by some of the identities (see Figure 1 for an overview of the 
feature). 
For this case, a separate PDU is assigned to each semantic group of signals. First, this is not efficient, because 
you maintain several PDUs which have the same semantic and transport the same signals. The memory 
consumption for these PDUs is redundant. Second, the application code or the software component should not 
need to distinguish between the different active identities when handling the contained signals.  
So the solution is to configure only one common PDU for all identities and use the potential for an optimization 
called PDU overlay (see the middle column of Figure 1). 
The needed PDU overlay must be configured manually. This means the user has to select the PDUs which can be 
merged together, and has to provide a respective control file in XML (Overlay Control File). 
In the PDUR one such PDU will result in the reception or transmission of a unique L-PDU on interface level. 
The configuration of the PDUR at startup will determine to which Rx or Tx L-PDU the I-PDU will be mapped, i.e. 
which CAN message will be sent with the contents of this I-PDU. 
Precondition:  
•  Existence of multiple ECU Extracts, one for each identity.  
•  An overlay control file. 
 
The figure below shows the tool flow for creating an ECUC file with an Overlay Control File: 
 
ECU Extract
of System
Overlay
Configuration
Control File
Description #1
ECU Extract
of System
Configuration
Initial ECUC
ECUC File
Description #2
Generator
.
.
ECU Extract
of System
Configuration
Description #n
 
Figure 2 – Creating an ECUC file with Overlay Control File 
 
 
6 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
Tool usage: 
GenTool_CsAsrInitialEcuC.exe [–p <PrjName>] –m [<EcuExtractOfSd1>…<EcuExtractOfSdN>] 
-o <OverlayControlFile> 
Hint: 
The optional parameter –p <PrjName> gives the name of the resulting configuration/project. The 
name of the resulting configuration and/or project is the first file name given to the generator tool if 
no – p <PrjName> option is given. In our example, the PrjName = DM_FRL. For the PDU overlay 
case, the PrjName can be given in the control file as well. 
Open a command line prompt and enter: 
GenTool_CsAsrInitialEcuC.exe -m DM_FL.arxml DM_FR.arxml DM_RL.arxml DM_RR.arxml -o 
MultiEcuExample.arxml 
You can also omit specifying the multiple ECU Extracts since the ECU Extracts are already referenced in the 
Overlay Control File. The following invocation is equivalent to the one above: 
GenTool_CsAsrInitialEcuC.exe -m -o MultiEcuExample.arxml 
2.3  Overlay Control File 
An example file is shown at the end of this chapter. Basically you have to define the following: 
•  The source extracts from which you read-in the different identities and a master extract which defines the 
default names of the merged entities. 
•  The instance name for the new ECU 
•  The PDU overlays (must be members of different identities) 
•  The signal overlays (for RTE fan in/out of signals with different PDU layout) 
•  Splitting of PDUs in Rx and Tx direction to explicitly define the overlay: Rx PDUs only, Tx PDUs only or Tx 
and Rx PDU overlay 
2.3.1  Specifying the ECU Extracts to be merged 
The ECU Extracts of System Configuration Description which shall be merged are specified within the 
<SourceECUExtracts> tag. You can specify a set of ECU Extracts (instances) to be merged via the 
<MergingExtract> tag and the master ECU Extract via the <MasterExtract>.  
Note: 
If an element (signal/PDU) is not present in the master extract, the default name of the element is 
defined by the order of the ECU Extracts in the <SourceECUExtracts> tag. 
 
See example below for specifying a set of ECU Extracts to be merged:  
<SourceECUExtracts> 
<MasterExtract> EcuExtractOfSd </MasterExtract> 
<MergingExtract> EcuExtractOfSd1 </MergingExtract> 
<MergingExtract> EcuExtractOfSd2 </MergingExtract> 
<MergingExtract> … </MergingExtract> 
</SourceECUExtracts> 
 
7 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
2.3.2  Specifying the merged ECU instance name 
The ECU instance name of the merged ECU is specified using the <NewECUInstanceName> tag: 
<NewECUInstanceName> MultiIdEcu </NewECUInstanceName> 
2.3.3  PDU overlay 
The PDU overlays are defined inside the <OverlayPDUs> tag, which contains all definitions for the overlays. The 
overlays consist of equivalent PDU names. The definition which PDUs shall be overlaid (“Rx”, “Tx” or “TxRx”) is 
specified by the direction parameter within the <OverlayingPDUs> tag. 
<OverlayPDUs> 
<OverlayingPDUs direction=”Tx”> 
<PDU>PDU1_FL</PDU> 
<PDU>PDU1_FR</PDU> 
<PDU> … </PDU> 
</OverlayingPDUs> 
</OverlayPDUs> 
Note: 
For overlaying PDUs, you also have to specify a corresponding signal overlay section in the 
overlay control file (see description below). 
2.3.4 Signal 
overlay 
The signal overlays for specifying the RTE fan in/out are defined inside the tag named <MatchingSignals> 
which contains all signals which shall be overlaid. Like the PDU overlay, the definition which signals shall be 
overlaid (“Rx”, “Tx” or “TxRx”) is given in the direction parameter of the <MatchingSignals> tag. 
The name of the overlaid signal is specified by the <NewSignalName> tag – see example below: 
<MatchingSignals direction=”Rx”> 
 <Signal>Signal1_FL 
</Signal> 
 <Signal>Signal1_FR</Signal> 
 
<Signal> … </Signal> 
 <NewSignalName>Signal1_XX</NewSignalName> 
</MatchingSignals> 
 
Please consider the following constraints when specifying signal overlays: 
•  For overlaying signal groups, you have to specify both the signal group and each group signal in the 
<Signal> tag. 
• The 
<MatchingSignals> tag is only evaluated by DaVinci Developer. The InitialEcuC Generator doesn’t 
verify the <MatchingSignals> section. 
•  The name of the resulting signal, specified by the <NewSignalName> tag shall correspond to the name of 
the port prototype in the System Description to enable DaVinci Developer to automatically map these 
signals. 
 
8 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
2.3.5  Splitting the direction of PDUs 
Within the <SplitTxRxPDUs> tag, you have to provide the PDUs which cannot be overlaid in both communication 
directions: 
<SplitTxRxPDUs> 
 <PDU>PDU1_FR</PDU> 
 <PDU>PDU1_FL</PDU> 
</SplitTxRxPDUs> 
2.3.6 Example 
<DVMultiECUConfiguration xmlns="http://www.vector-informatik.de/MultiECUSupport" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.vector-informatik.de/MultiECUSupport 
MultiEcuConfig.xsd" version="1.0"> 
    <SourceECUExtracts> 
        <MasterExtract>DoorECU_FL</MasterExtract> 
        <MergingExtract>DoorECU_FR</MergingExtract> 
        <MergingExtract>DoorECU_RL</MergingExtract> 
        <MergingExtract>DoorECU_RR</MergingExtract> 
    </SourceECUExtracts> 
    <NewECUInstanceName>MyMultiDoorECU</NewECUInstanceName> 
    <OverlayPDUs> 
        <OverlayingPDUs> 
            <PDU>PDU1_FL</PDU> 
            <PDU>PDU1_FR</PDU> 
            <PDU>PDU1_RL</PDU> 
            <PDU>PDU1_RR</PDU> 
        </OverlayingPDUs> 
        <OverlayingPDUs direction="TxRx"> 
            <PDU>PDU2_FL</PDU> 
            <PDU>PDU2_FR</PDU> 
        </OverlayingPDUs> 
        <OverlayingPDUs direction="Tx"> 
            <PDU>PDU3_FL</PDU> 
            <PDU>PDU3_FR</PDU> 
        </OverlayingPDUs> 
        <OverlayingPDUs direction="Tx"> 
            <PDU>PDU3_RL</PDU> 
 
9 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
            <PDU>PDU3_RR</PDU> 
        </OverlayingPDUs> 
        <OverlayingPDUs direction="Rx"> 
            <PDU>PDU3_FR</PDU> 
            <PDU>PDU3_RR</PDU> 
        </OverlayingPDUs> 
        <OverlayingPDUs direction="Rx"> 
            <PDU>PDU3_FL</PDU> 
            <PDU>PDU3_RL</PDU> 
        </OverlayingPDUs> 
    </OverlayPDUs> 
    <MatchingSignals> 
        <MatchingSignals direction="TxRx"> 
            <Signal>Signal1_FL</Signal> 
            <Signal>Signal1_FR</Signal> 
            <Signal>Signal1_RL</Signal> 
            <Signal>Signal1_RR</Signal> 
            <NewSignalName>Signal1</NewSignalName> 
        </MatchingSignals> 
        <MatchingSignals> 
            <Signal>Signal2_FL</Signal> 
            <NewSignalName>Signal2</NewSignalName> 
        </MatchingSignals> 
    </MatchingSignals> 
    <SplitTxRxPDUs> 
        <PDU>PDU3_FL</PDU> 
        <PDU>PDU3_FR</PDU> 
        <PDU>PDU3_RL</PDU> 
        <PDU>PDU3_RR</PDU> 
        <PDU>PDU4</PDU> 
    </SplitTxRxPDUs> 
</DVMultiECUConfiguration> 
 
Note: 
There is an XML schema file (MultiEcuConfig.xsd) which is part of the SLP10 delivery that helps 
you to create a valid PDU overlay control file. 
 
 
10 
Application Note  AN-ISC-8-1102 
 



 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
2.4  ECUC creation using DaVinci Project Assistant 
DaVinci Project Assistant supports you in setting up a project based on an existing control file (see  2.3) or on the 
ECU extracts of the different identities. It automatically creates the initial active ECU configuration. 
When specifying the input files for the project, you may select Multiple ECU. You may now either provide the 
existing control file or the ECU extracts and a location for an automatically created control file. This automatically 
created control file will contain the specified ECU extract references. 
Note: 
To define the PDU overlay (see  2.2) you need to manually edit the control file. 
 
Figure 2 – DaVinci Project Assistant Input Files Specification 
 
If you change the control file after having created the project, you may use the update function of the DaVinci 
Project Assistant to reflect your changes. 
Note: 
DaVinci Project Assistant resolves the references to the identities’ extracts given in the control file 
relative to the control file’s location. 
2.5  Generating the RTE of a Multiple ECU 
To generate the RTE of a Multiple ECU, the different ECU extracts – each containing the description of a single 
identity – need to be merged into a single ECU project representing all identities of the Multiple ECU. The merged 
ECU project (resp. an ECU Extract of System Description created by DaVinci Developer) is compatible to the 
ECUC (see  2.0) and can be used as input for the MICROSAR RTE generator. 
The merged ECU project is created by the DaVinci Project Assistant. Alternatively, you may import an existing 
control file (see  2.3) into a DaVinci Developer workspace using the standard XML import mechanism. This will 
automatically create the merged ECU project. 
Note: 
DaVinci Developer resolves the references to the identities’ extracts given in the control file relative 
to the control file’s location. 
3.0  Initialization of the BSW 
The ECU State Manager (ECUM) implements the support for Multiple ECUs. The scope of this chapter is restricted 
to the characteristic settings for Multiple ECUs in the ECU State Manager only. Further initialization steps 
necessary for AUTOSAR systems are not described here and are assumed to be known. 
 
11 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
The BSW initialization procedure in AUTOSAR works the following way: 
•  µC startup code execution (out of AUTOSAR scope). 
•  Call of the main() function Æ EcuM_Init() 
•  EcuM_Init() allows for initialization of the BSW modules on low level 
•  EcuM_Init() starts the OS, EcuM_Init() does never return. 
•  Schedule Manager Task starts and calls the EcuM_StartupTwo() in its task body 
•  EcuM_StartupTwo(): calls SchM_Init() and calls DriverInitListTwo 
•  The initialization for Multiple ECUs takes place in DriverInitListTwo… 
 
The ECU State Manager (ECUM) itself does not allow different initializations in the EcuM_Init() function. The 
following ECUM properties will be defined only once and are commonly valid for all identities inside an ECUC for a 
Multiple ECU: 
• Sleep 
modes 
• Wake-up 
Sources 
• ECUM 
Users 
• COMM 
channels 
•  TTII successors and divisors 
• DriverInitLists 
 
The ECU firmware (more precisely: a user defined equivalent to an ECU State Manager initialization list) has to 
decide which identity is presently active and has to call the proper initialization routines for the basic software 
modules.  
This initialization approach will 
•  Not adjust the application logic accordingly. The application implements a superset of all functions and is 
not necessarily aware of different identities. 
•  Set up the corresponding BSW modules correctly. 
 
There is no tool-guided way to configure the ECUM for multiple ECU support. Only a manual solution is possible. 
For this purpose, an initialization function has to be added to the STARTUP II phase of the ECUM. (This is 
because the communication modules implement this feature. Communication modules are typically initialized 
during STARTUP II). This can be accomplished by adding a function call to EcuM_Pbcfg.c for the ECUM inside 
the configuration tool (for the SLP10, this can be done inside GENy, for other stacks this is DaVinci Configurator 
Pro). The necessary steps are described below. 
3.1  Creation of the logic for identity selection 
The Multiple ECU support requires a user defined function which determines for which identity the ECU shall start 
up. As described in the paragraph before, this extension has to be built into the STARTUP II. 
Further, we assume that you provide this function in the files  
EcuM_MultiIdentitySupport.h  
EcuM_MultiIdentitySupport.c 
 
The function which has to be called in STARTUP II itself may be called  
EcuM_MultiConfigSelection() 
 
12 
Application Note  AN-ISC-8-1102 
 




 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
 
Note:  
The name of the header and C file are only examples, as well as the signature and function name 
EcuM_MultiConfigSelection(). The actual implementation is up to the supplier. 
3.2  Prepare the ECUM configuration 
Before you can use the Multiple ECU feature, you have to add EcuM_MultiIdentitySuport.h  to the  
Additional Includes section in the ECUM. 
 
Figure 3 – GENy Configuration for Multiple ECU Feature 
 
Further, you have to create a new entry in the ECUM Driver Init List Two, where 
EcuM_MultiConfigSelection() is called. 
 
Figure 4 - GENy Configuration for Init List Two 
 
3.3  Provide an user defined ECUM initialization function 
An implementation for the MultiConfigSelection initialization function could look like that: 
… 
#include <EcuM_MultiIdentitySupport.h> 
… 
void EcuM_AL_DriverInitTwo () /*  

  Dio_Init(); 
  EcuM_MultiConfigSelection(); 

 
13 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
You will need to provide a similar implementation in EcuM_MultiIdentitySupport.c: 
FUNC(void, ECUM_CODE) EcuM_MultiConfigSelection(void) 

  channelGroupIdType dioDipSwitch; 
 
  switch (Dio_ReadChannelGroup(&dioDipSwitch))  /* read in DIP switch */ 
  { 
    case MULTI_CONFIG_FL: /* initialization variant for door front left */ 
      Can_Init(NULL_PTR);  
      CanIf_Init(NULL_PTR); 
      CanSM_Init(); 
      PduR_Init(&PduRGlobalConfig_DM_FL); 
      Com_Init(NULL_PTR); 
      Nm_Init(NULL_PTR); 
      CanNm_Init(&CanNmGlobalConfig_DM_FL); 
      ComM_Init(); 
      CanTp_Init(&CanTpConfigSet_DM_FL); 
      Dcm_Init(&DcmConfigSet_DM_FL); 
      Vmm_Init(); 
      Dem_Init(); 
    break; 
    case MULTI_CONFIG_FR: /* initialization variant for door front right */ 
      Can_Init(NULL_PTR);  
      CanIf_Init(NULL_PTR); 
      CanSM_Init(); 
      PduR_Init(&PduRGlobalConfig_DM_FR); 
      Com_Init(NULL_PTR); 
      Nm_Init(NULL_PTR); 
      CanNm_Init(&CanNmGlobalConfig_DM_FR); 
      ComM_Init(); 
      CanTp_Init(&CanTpConfigSet_DM_FR); 
      Dcm_Init(&DcmConfigSet_DM_FR); 
      Vmm_Init(); 
      Dem_Init(); 
    break; 
    default:  
    break; 
  } 
 
14 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
  return; 
}  
 
Inside each initialization sequence, there have to be instance-specific calls into the basic software init functions like 
 <BSWM>_Init(&<configSetPtrName>_<EcuShortName>) 
Each module has to provide the instance-specific <configSetPtrName>_<EcuShortName> in its actual 
configuration obtained by the BSW configuration step performed in GENy. 
The name of the parameter used for the init functions is formed according to the following rule: 
<configSetPtrName> comes from the structure name from bswmd/paramdef file. 
<EcuShortName> is derived of the Ecu Names used in the ECU Extract of System 
Description 
Note: 
You do not have the same scheme for the init functions of all BSW modules, some take no 
arguments some take a mandatory pointer. The following section provides an overview. 
3.4  Where do I find the initialization structures? 
For each BSW module, you can find the init structures in the generated code. Simply have a look at the following 
files in the \gendata folder: 
<ModuleName>_lcfg.c, <ModuleName>_pbcfg.c, <ModuleName>_cfg.c 
3.5  Overview of BSW module initialization 
Considering the Multiple ECU feature, the AUTOSAR selectable post build approach is not fully supported.  The 
AUTOSAR selectable post build approach is based on different unique initialization structures which are passed to 
the BSW via an initialization pointer in order to configure it. 
Resource optimization would not be possible if unique initialization structures for each identity were provided. For 
this reason, the AUTOSAR selectable post build initialization mechanism is not applied for all modules. 
For the majority of the modules, only one merged post build configuration/superset of initialization data will be 
created in order to save resources. For the remaining modules DCM, CANTP, CANNM, IPDUM, PDUR, individual 
initialization data sets are supported. 
The following table gives an overview of the configuration pointer usage. 
 
Used init pointer 
BSW 
Not instance specific 
Instance specific 
module 
COMM 

 
ECUM 

 
VMM 

 
COM 

 
IPDUM  

PDUR  

NM 

 
CANNM  

CANSM 

 
 
15 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
CANIF 

 
CANDRV 

 
CANTP  

DCM  

DEM 

 
Table 1  – Overview of the module configuration for multiple identities 
 
4.0  Diagnostics and Multiple ECU Support 
The DCM/DEM module, developed by Vector, implements two dynamic configuration modes that allow switching 
among the available configuration sets at runtime (without need to reprogram the ECU). This requires that the 
superset of all variants must be pre-enabled during the software compilation and link process.  
 
In Multiple ECU mode, DCM allows you to use: 
•  Multiple diagnostic configuration sets – a use case where the ECU always communicates over the same 
connection, but shall implement different functionality depending on some hardware (jumper) setting. 
•  Multiple communication configuration sets – typical use case where the ECU shall have the same 
functionality, but depending on its location on the network uses different communication parameters 
(communication message IDs i.e. door ECUs). 
•  Both multiple diagnostic and communication sets. 
 
The combination of diagnostic and communication configuration is configured statically in GENy.  
The details of Multiple ECUs and diagnostics are described in the Technical Reference for the DCM, chapter 7.6 
and in the Technical Reference for the DEM, chapter 7.1. 
5.0  Supported use cases 
Based on the PDU overlay and RTE fan in/out approach, the current implementation of the Multiple ECU supports 
the following use cases: 
•  Overlaying of RX/TX PDUs with identical signal layout, respective PDUs with gaps in the signal layout. 
Each signal within the PDU has to have the same length and has to be of the same type: Single signals 
can only be overlaid by single signals, signal groups can only be overlaid by signal groups. 
•  RTE fan in/out of signals which are located in different PDUs. 
6.0  Restrictions and limitations 
LIN is invariant to the Multiple ECU feature that means it is not actively supported. As a consequence, the same 
LIN network exists in all identities. Multiple ECU support for FlexRay is planned for future releases. 
Please also note the for RTE fan in, the signals to be overlaid have to be located in different PDUs 
 
16 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
If a PDU contains signals for different identities, a wrapper software component needs to be implemented to select 
the according signal based on the current identity – see example below: 
 
Wrapper SWC
SWC
Signal_XX
Identity
al_FL
al_FR
al_RL
al_RR
gn
gn
gn
gn
Si
Si
Si
Si
 
Figure 4 – Wrapper software component for switching identity specific signals 
 
 
7.0 Additional resources 
VECTOR TECHNICAL REFERENCES 
MICROSAR DCM Technical Reference (based on ASR 3.0) Version 3.14 
MICROSAR Diagnostic Event Manager (DEM) Technical Reference Daimler Version 2.2 
 
17 
Application Note  AN-ISC-8-1102 
 


 
 
Identity Manager - Multiple ECUs 
 
 
 
 
 
 
8.0 Contacts 
 
 
 
 
Germany  
France, Belgium, Luxemburg: 
Sweden, Denmark, Norway,  
and all countries not named below: 
 
Finland, Iceland: 
Vector Informatik GmbH 
Vector France SAS 
VecScan AB 
Ingersheimer Str. 24 
168 Boulevard Camélinat 
Theres Svenssons Gata 9 
70499 Stuttgart 
92240 Malakoff  
41755 Göteborg  
GERMANY 
FRANCE 
SWEDEN 
Phone: +49 711-80670-0 
Phone: +33 1 42 31 40 00 
Phone: +46 31 764 76 00 
Fax: +49 
711-80670-111 
Fax: 
+33 1 42 31 40 09 
Fax: 
+46 31 764 76 19  
E-mail: info@de.vector.com 
E-mail: information@fr.vector.com 
E-mail: info@se.vector.com 
 
 
 
 
  
 
United Kingdom, Ireland: 
China: 
India: 
Vector GB Ltd. 
Vector Informatik GmbH  
Vector Informatik India Private Ltd. 
Rhodium 
Shanghai Representative Office 
4/1/1/1 Sutar Icon 
Central Boulevard 
Suite 605, Tower C,  
Sus Road 
Blythe Valley Park 
Everbright Convention Center 
Pashan 
Solihull, Birmingham 
No. 70 Caobao Road 
Pune 411021 
West Midlands B90 8AS 
Xuhui District 
INDIA 
UNITED KINGDOM 
Shanghai 200235  
 
Phone: +44 121 50681-50 
P.R. CHINA 
Phone: +91 9673 336575 
E-mail: info@uk.vector.com 
Phone: +86 21 - 6432 5353 ext. 0 
E-mail: info@vector-india.com 
 
Fax:   +86 21 - 6432 5308 
E-mail: info@vector-china.com 
 
 
 
 
USA, Canada, Mexico: 
Japan: 
Korea: 
Vector CANtech, Inc. 
Vector Japan Co. Ltd. 
Vector Korea IT Inc. 
39500 Orchard Hill Pl., Ste 550 
Seafort Square Center Bld. 18F 
#1406, Mario Tower, 
Novi, MI  48375 
2-3-12, Higashi-shinagawa, 
222-12 Guro-dong, Guro-gu  
USA 
Shinagawa-ku 
Seoul, 152-848 
Phone: +1 248 449 9290 
Tokyo 140-0002 
REPUBLIC OF KOREA 
Fax: 
+1 248 449 9704 
JAPAN 
Phone: +82 2 807 0600 
E-mail: info@us.vector.com 
Phone: +81 3 5769 7800 
Fax: 
+82 2 807 0601 
 
Fax: 
+81 3 5769 6975 
E-mail: info@kr.vector.com 
E-mail: info@jp.vector.com 
 
 
 
 
 
18 
Application Note  AN-ISC-8-1102 
 

Document Outline


9 - ApplicationNotes_DifferenceAnalyzer

Microsoft Word - ApplicationNotes_DifferenceAnalyzer.doc

11 - ApplicationNotes_DifferenceAnalyzers


 
 
 
 
 
 
 
 
 
 
 
 
DaVinci Difference Analyzer 
Application Note 
 
 
 
 
Version 1.7 
 
 
 
 
 
 
Authors: 
Stefanie Kruse, Matthias Wernicke, Andreas 
Claus, Daniel Fürderer 
Version: 
1.7 
Status: 
released  
 
 
 


DaVinci Difference Analyzer Application Note 
 
History 
 
Author  Date 
Version  Remarks 
Ske 
2009-05-20 
1.0 
Initial version 
Ske 
2009-06-10 
1.1 
Description of starting DaVinci Difference Analyzer enhanced 
Wk 
2009-07-29 
1.2 
Document restructured and completed 
Cs 
2011-06-28 
1.3 
Description of filter options added 
Dfr 
2012-01-24 
1.4 
Updated figures and added description of view options (3.6), 
Parent Path (3.7) and DPA compare (3.8) 
Cs 
2012-05-02 
1.5 
Additional Copyrights added 
Dfr 
2014-01-28 
1.6 
Added description of ‘Filter equal elements’ option (3.5.2 and 4) 
Cs 
2015-05-28 
1.7 
Usage of Saxon-PE distributable package 
 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
Contents 
1 
Overview ................................................................................................................... 5 
2 
Installation ................................................................................................................ 6 
2.1 
Setup program ............................................................................................ 6 
2.2 
Licensing .................................................................................................... 6 
3 
Using DaVinci Difference Viewer ............................................................................. 7 
3.1 
Starting the difference analysis ................................................................... 7 
3.2 
Display of the differences ........................................................................... 8 
3.3 
Saving the result of a difference analysis .................................................... 9 
3.4 
Opening the result file of a difference analysis ............................................ 9 
3.5 
Filter Options .............................................................................................. 9 
3.5.1 
Element Identification ............................................................................... 10 
3.5.2 
Filter equal elements ................................................................................ 11 
3.5.3 
Element Filter ........................................................................................... 11 
3.5.4 
Loading/Storing Options ........................................................................... 11 
3.6 
View Options ............................................................................................ 11 
3.7 
Parent path changes ................................................................................ 12 
3.8 
Comparing DPA Projects .......................................................................... 12 
3.8.1 
Starting the difference analysis ................................................................. 12 
3.8.2 
Result Overview ....................................................................................... 12 
4 
Command line usage ............................................................................................. 14 
5 
Result file ................................................................................................................ 15 
6 
Additional Copyrights ............................................................................................ 17 
6.1 
Saxon-HE ................................................................................................. 17 
6.1.1 
IKVM Runtime .......................................................................................... 17 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
7 
Contact .................................................................................................................... 18 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
1   Overview 
This document explains the usage of the command line tool “DaVinci Difference Analyzer” 
Version 2.7 and tells how to interpret the result.  
 
DaVinci  Difference  Analyzer  compares  two  ARXML  files  and  puts  the  result  into  a  result 
file.  Additionally  you  can  compare  two  DaVinci  Project  Assistant  projects  by  their  DPA 
files. For further information on DPA compare see chapter 3.8. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
2  Installation 
2.1  Setup program 
The  DaVinci  Difference  Analyzer  can  be  installed  by  starting  the  setup  program 
DaVinciDiff.msi. This setup is part of a DaVinci tool setup and is installed during the tool 
installation procedure. 
The DaVinci Difference Analyzer is installed into one of the following folders: 
n  
English Windows: C:\Program Files\Common Files\Vector 
n  
German Windows: C:\Programme\Gemeinsame Dateien\Vector 
The following executables are installed in the sub-folder “DiffAnalyzer”: 
n  
DVDiffSys.exe: Command line program for comparing AUTOSAR XML files 
(System Description files, Software Component Description files or ECU 
Configuration Description files) 
n  
DVDiffView.exe: Program for displaying the differences between two AUTOSAR 
XML files 
2.2  Licensing 
In order to run DaVinci Difference Analyzer a license of at least one of the following tools is 
required on the PC: 
n  
DaVinci Configurator Pro 
n  
DaVinci Developer 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
3  Using DaVinci Difference Viewer 
3.1  Starting the difference analysis 
The difference analysis can be started via one of the following options 
 
n  
Via the Program menu 
Using Program menu | <DaVinci tool, e.g. Vector DaVinci Configurator 4.0> 
| DaVinci Difference Viewer the DaVinci Difference Viewer is started. Using 
File | New you can open a dialog for selecting the two AUTOSAR XML files to 
be compared. After confirming this dialog, the comparison is started and the 
differences are displayed. 
n   Via the Windows Explorer 
After selecting two files with extension .arxml in the Windows Explorer, you can 
display the differences between these files using the context menu entry 
AUTOSAR XML Diff 
 
 
Figure 1: Analyze two files with the shell extension of DaVinci Difference Analyzer 
 
Alternatively, you can select the first file, use the context menu entry Select as left 
side for AUTOSAR XML Diff 
 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 




DaVinci Difference Analyzer Application Note 
 
 
Figure 2: Select source file to compare AUTOSAR files with the DaVinci Difference Analyzer 
 
 
and then select the second file and context menu entry AUTOSAR XML Diff with 
 
 
Figure 3: Shell Extension of DaVinci Difference Analyzer 
3.2  Display of the differences 
The  differences  are  displayed  in  the  DaVinci  Difference  Viewer  (Figure  4:  DaVinci 
Difference Viewer). 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
 
Figure 4: DaVinci Difference Viewer 
3.3  Saving the result of a difference analysis 
Using File | Save As you can save the results of the difference analysis can be saved to a 
DaVinci Difference File (extension .dvdiff, see chapter 5). 
3.4  Opening the result file of a difference analysis 
After opening the DaVinci Difference Viewer you can load a DaVinci Difference File using 
File | Open. Alternatively you can doubleclick the DaVinci Difference File in the Windows 
Explorer. 
3.5  Filter Options 
A  dialog  can  be  opened  using  Tools  |  Options  to  specify  the  element  identification  and 
filter for the next comparison. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
 
Figure 5: Options Dialog 
If  options  are  modified  and  the  dialog  has  been  closed  using  OK  you  can  re-start  the 
comparison process with the currently selected files by using the File | Reload 
3.5.1 
Element Identification 
Elements can be identified by Short-Name or UUID: 
n  
Short-Name 
The elements have to be in the same package and the Short-Name has to be 
identical. This means if an element is renamed or was moved to another 
package it will be shown as removed in the source file and added in the changed 
file.  
n  
UUID 
In UUID-Mode the elements are identified by their UUID. Thus Short-Name or 
package modifications are shown as a usual modification. If an element does not 
have an UUID, it is identified by Short-Name or if it does not have a Short-Name 
it is identified according to its position. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
3.5.2 
Filter equal elements 
Enabling  filter  equal  elements  (see  Figure  6:  Filter  equal  elements  option)  will  remove 
equal  AR-ELEMENTS  from  differing  process.  This  option  will  speed  up  the  diff  process, 
but you cannot see equal elements in the DaVinci Difference View (see 3.6 View Options). 
 
Figure 6: Filter equal elements option 
3.5.3 
Element Filter 
To ignore certain elements during the comparison the XML element can be added to the 
ignorer  list.  These  ignored  elements  do  not  exist  in  the  diff  result  file.  For  hierarchical 
elements all children of ignored elements are ignored too. 
3.5.4 
Loading/Storing Options 
The currently defined options can be stored as a configuration for later usage. By pressing 
the  New...  button  the  configuration  is  created  with  the  given  name.  With  Select…  the 
options can be loaded from a stored configuration. 
The  configurations  are  stored  in  the  file  DVUserDefinedConfiguration.ini  located  in  the 
shared documents folder for all users: 
n  
English Windows:  
C:\Documents and Settings\All Users\Documents\Vector\DaVinci\DiffAnalyzer 
n  
German Windows:  
C:\Dokumente und Einstellungen\All 
Users\Dokumente\Vector\DaVinci\DiffAnalyzer 
3.6  View Options 
The view options enable you to filter elements by their changes. Elements are considered 
as equal, modified, added or removed. The buttons from the toolbar (Figure 7: View 
Options) toggle between showing and hiding elements of the specific category. Thus you 
can configure your specific view of a diff, e.g. show only new elements. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 




DaVinci Difference Analyzer Application Note 
 
 
Figure 7: View Options 
3.7  Parent path changes 
In the options (see chapter 3.5.1) the identification type of an element can be set. While in 
short-name mode elements are identified by their short-name within the same package, in 
UUID  mode  it  is  possible  to  identify  elements  across  different  packages  by  UUID.  The 
AUTOSAR  path of  the  parent  element  is  introduced  to  visualize  changes  of the  package 
structure. 
In  the  viewer  you  can  define  weather  you  want  to  care  about  changes  of  the  package 
structure or not. If only the parent path was modified and the parent path is set to ignore 
the element is considered as equal. 
 
Figure 8: Show/Hide parent path changes 
Note: The parent path button is only activated if the file was compared with UUID-
identification. A refresh is required if you change the element identification in the options 
dialog. 
3.8  Comparing DPA Projects 
3.8.1 
Starting the difference analysis 
To compare two DPA projects you can choose one of the described starting methods 
(3.1). In the open file dialog you have to change the file extension filter to ‘DaVinci Files 
(*.arxml, *.dpa)’. The result is presented in the Result Overview (Figure 9: DPA project 
comparison) which is immediately opened.  
3.8.2 
Result Overview 
In the Result Overview (Figure 9: DPA project comparison) a listed of items to compare is 
shown. An item can be a value of the project configuration itself, e.g. the project name or 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
binary files like DLLs or AUTOSAR files which are part of the project. At any time you can 
show or hide the Result Overview over the View | Result Overview menu or pressing the 
shortcut ‘Ctrl+r’. 
The status column signalize if a value was compared. For AUTOSAR files a file icon 
appears and the difference result view can be shown by double clicking the row. 
 
Figure 9: DPA project comparison 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
4  Command line usage 
You can run the difference analysis by the following command: 
DVDiffSys  –s <arfile1> -c <arfile2> -o <resultfile>  
[-r  [-e < schemafile>]] 
[-u] [-p <presetname>] [-fe <XMLElementName1[,XMLElementNameN]*>] 
 
n  
Mandatory parameters 
n   –s <arfile1> source file. 
n   –c <arfile2> AUTOSAR file which is compared with the source file. 
n   –o  <resultfile>  path  of  an  xml  result  file  which  contains  the  differences 
between <arfile1> and <arfile2>. 
 
n  
Optional parameters 
n   –p  <presetname>  Name  of  the  preconfigured  configuration  containing  the 
options and filter definitions.  
n   –fe  <XMLElementName1[,XMLElementNameN]*>  List  of  elements  to  be  ignored 
during comparison.  If –p and –fe is specified the filter list will be appended to 
the preconfigured filters 
n   –r  validation  of  AUTOSAR  files  against  the  xml  schema  referenced  within  the 
source/changed  file.  If  this  parameter  is  not  specified  validation  is  disabled  by 
default. 
n   –r  -e  <schemafile>  The  AUTOSAR  files  are  validated  against  the  defined 
external xml schema.  
n   –u use UUID instead of short name to identify objects.  
n   -fee  To  speed  up  the  diff  process  equal  AR-ELEMENTs  are  excluded  from 
diffing. In the Difference Viewer it is not possible to show equal AR-ELEMENTS 
when enabling the equal elements filter (see 3.6 View Options). 
 
Note:  DaVinci  Difference  Analyzer  supports  AUTOSAR  2.1,  AUTOSAR  3.x,  and 
AUTOSAR 4.x 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 



DaVinci Difference Analyzer Application Note 
 
5  Result file 
The  results  of  a  difference  analysis  can  be  stored  in  a  DaVinci  Difference  File  (XML  file 
with extension .dvdiff).  
 
Description of the XML tags: 
n  
MASTER-FILE  
Specifies the master (source) file of the comparison. The attribute “file” specifies an 
absolute or relative file path. 
n  
MODIFIED-FILE 
Specifies  the  modified  file  to  compare  with  the  master  file.  The  attribute  “file” 
specifies an absolute or relative file path. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
n   CONFIGURATION 
Used options for this comparison including the full list of ignored elements 
n  
CHANGED 
Specifies that the object itself or one or more if its children had been changed. The 
attribute “type” specifies the type of the object. The attribute “short-name” specifies 
the name of the object. 
If something is changed somewhere in the sub branch, the object is followed by a 
<CHANGED>, <ADDED> or <REMOVED> tag.  
If the value of the object itself is changed, the object is followed by an <OLD> and 
<NEW> tag. 
n  
ADDED 
Specifies  the  object  and  its  children  have  been  added  to  the  modified  file.  The 
attribute “type” specifies the type of the object. The attribute “short-name” specifies 
the name of the object. 
n  
REMOVED 
Specifies the object and its children have been removed from the master file. The 
attribute “type” specifies the type of the object. The attribute “short-name” specifies 
the name of the object. 
n  
OLD 
Value of an object in master file. 
n  
NEW 
Value of an object in modified file. 
n  
NO_CHANGES 
Files are equal. 
n  
NO_AUTOSAR 
File is not an AUTOSAR file. 
n  
EQUAL 
Elements are equal. 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
6  Additional Copyrights 
6.1  Saxon-PE Redistribution 
Difference algorithm is executed using XSLT style-sheets processed by "The Saxon XSLT 
and XQuery Processor from Saxonica Limited" available at http://www.saxonica.com/.  
 
DaVinci  Difference  Analyzer  links  to  the  Saxon-PE  binary  libraries.  The  libraries  are 
distributed as separate binary DLL files. No modifications have been made to the libraries. 
6.1.1 
IKVM Runtime 
Saxon links dynamically to the IKVM Runtime. See http://www.ikvm.net/.  
Can be downloaded from http://sourceforge.net/projects/ikvm/files/ 
License is at http://weblog.ikvm.net/story.aspx/license 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 


DaVinci Difference Analyzer Application Note 
 
7  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector-informatik.com 
2015, Vector Informatik GmbH 
Version: 1.7 
 
 

12 - LicenseManagerHelp

Vector Product Activation

14 - LicenseManagerHelps


 
 
 
 
 
 
 
 
 
 
 
Vector Product Activation 
 
 
 
 
Version 2.0 
 
 
 
 
 
 
 
 
 
 
 
Status 
Released 
 
 
 
 
 



 Vector Product Activation  
 
Contents 
1  Overview ......................................................................................................................... 3 
2  Activate / Update a License ........................................................................................... 4 
2.1 
Activate / Update a License from Vector Activation Server .............................. 4 
2.1.1 
Activate / Update a License via Internet .......................................................... 4 
2.1.2 
Activate / Update a License via E-mail ............................................................ 5 
2.2 
Activate / Update a License from Local License Server ................................... 9 
3  Extend a License .......................................................................................................... 12 
3.1 
Extend a License against Local License Server ............................................ 12 
4  Return a License .......................................................................................................... 14 
4.1 
Return a License to Vector Activation Server ................................................. 14 
4.1.1 
Return a License via Internet ......................................................................... 14 
4.1.2 
Return a License via E-mail ........................................................................... 14 
4.2 
Return a License to a Local License Server .................................................. 15 
5  Repair Licenses ............................................................................................................ 16 
5.1 
Repair Licenses against Vector Activation Server .......................................... 16 
5.1.1 
Repair a License via E-mail ........................................................................... 17 
5.2 
Repair a License against a Local License Server .......................................... 20 
6  FAQs and Background Information ............................................................................ 21 
7  Contact.......................................................................................................................... 22 
 
2011, Vector Informatik GmbH 
Version: 2.0 
2 / 22 
based on template version 4.5 



 Vector Product Activation  
 
1  Overview 
In the product activation process only data relevant to the installation  is transferred. 
Vector uses the acquired data exclusively for product activation. 
To activate the product open the Product License Manager. The required Activation ID 
can be found on the cover of the Product CD or in your delivery e-mail
You can choose between two different methods of product activation:  
1.  Online: Automatically via the Internet (recommended, since no time delay) 
2.  By e-mail to: activation@vector-worldwide.com  
If you choose activation by e-mail, send the activation request generated in the Product 
License Manager
 as an e-mail attachment to Vector. In response Vector will send you a 
License Certificate by e-mail which you will need to enter in the License Manager. If this 
is a first-time activation, the initial step involves an additional e-mail exchange to obtain 
Hardware Certificate for configuring license management on your computer. 
If you have any further questions please feel free to contact us. 
2011, Vector Informatik GmbH 
Version: 2.0 
3 / 22 
based on template version 4.5 




 Vector Product Activation  
 
2  Activate / Update a License 
2.1 
Activate / Update a License from Vector Activation Server 
2.1.1 
Activate / Update a License via Internet 
To activate or update a license via Internet from the Vector Activation Server, open the Li-
cense Manager and follow these instructions. 
Step 1 Select License Keys / Activate Manually / Vector Activation Server in the main 
menu of the License Manager. 
 
Figure 2-1 
Select Activate a new license 
Step 2 For request method, we recommend using by internet connection if you have Inter-
net access (should you trust Vector software to connect to the Internet? See section 3 Ex-
tend a License.) 
2011, Vector Informatik GmbH 
Version: 2.0 
4 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 2-2 
Send request by internet connenction 
Step 3 Enter your Activation or Update ID (from the cover of the product CD or in your de-
livery e-mail). Please ensure that you typed the ID  correctly  (case sensitive, including all 
zeros). 
Step 4 Ensure that you typed the Activation ID correctly. Press OK. Once the license has 
been correctly transferred to your PC, you’ll see a respective message. You’re done. 
 
 
Info 
In case a HTTP proxy is present in your network that requires a password and/or a 
  login you will be prompted for that data. 
 
 
 
2.1.2 
Activate / Update a License via E-mail 
To activate or update a license via Email (only recommended if activation via Internet 
doesn't work), open the License Manager and follow these instructions: 
Step 1 Select License Keys / Activate Manually / Vector Activation Server in the main 
menu of the Product License Manager. 
Step 2 For Request method, select Send request by e-mail 
2011, Vector Informatik GmbH 
Version: 2.0 
5 / 22 
based on template version 4.5 




 Vector Product Activation  
 
 
Figure 2-3 
Select Send request by e-mail 
Step 3 Enter your Activation / Update ID (from the cover of the product CD or delivery e-
mail). Please ensure that you typed the ID  correctly  (case sensitive, including all zeros). 
Press OK. 
Step  4  Save the request as a file to any location on your hard disk using button “Save 
as…”. 
2011, Vector Informatik GmbH 
Version: 2.0 
6 / 22 
based on template version 4.5 




 Vector Product Activation  
 
 
Figure 2-4 
Save the request 
Step 5 Press Open e-mail… to automatically open a new e-mail with the saved file as at-
tachment. If this fails, attach the file manually to a new e-mail. 
 
Step  6  Send this e-mail to Vector (activation@vector-worldwide.com). No special subject 
or formatting of your e-mail is required. 
 
Step 7 Press OK to close the dialog. 
 
Step 8 If you then received a certificate via e-mail from Vector, save the certificate from the 
e-mail as a file to any location on your hard disk. Open the License Manager again. 
 
Step 9 Select License Keys / Continue e-mail transaction
2011, Vector Informatik GmbH 
Version: 2.0 
7 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 2-5 
Select Continue e-mail transaction 
Step 10  In the Loading the certificate dialog, press button Load certificate…  and select 
the certificate file stored on your hard disk (in step 8). 
 
Figure 2-6 
Load certificate… 
 
2011, Vector Informatik GmbH 
Version: 2.0 
8 / 22 
based on template version 4.5 





 Vector Product Activation  
 
Step 11 If this is the first time that you activate a Vector product on your PC, the certificate 
you received configured only your PC itself; you need a second tour (send request to Vec-
tor, receive and load the certificate). Otherwise, you’re done! 
2.2 
Activate / Update a License from Local License Server 
 
 
Info 
In case your company maintains its own license server for Vector products, follow the 
  steps described below. For questions regarding locally administrated settings (server 
URL, activation IDs for license pools) please contact your local network administrator 
or IT department. 
 
 
To activate or update a license from a local license server, open the License Manager and 
follow these instructions: 
Step 1  Select  License Keys  /  Activate Manually / Local License Server  in the entry 
screen of the License Manager. 
 
Figure 2-7 
Select License server type: Local license server 
 
Step 2 Enter your Activation or Update ID (from the cover of the product CD or delivery e-
mail), the URL of the local license server and the expiration date. 
2011, Vector Informatik GmbH 
Version: 2.0 
9 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 2-8 
Enter your Activation or Update ID and server URL 
Please ensure that you typed the Activation ID  correctly  (case sensitive, including all ze-
ros). 
If your local license server is run with default settings, please enter the server URL 
@myLicenseServerName.com (@ sign must be provided), where the actual server name 
is defined by your network administrator or IT department. 
In case customized settings for TCP ports are used also provide the respective TCP port 
number, please  (example: license server listens on TCP port 47811  
47811@myLicenseServerName.com). 
 
Servers can be configured with Settings / Server Configuration.  
 
Figure 2-9 
Server Configuration 
Add your server into the list of known servers. 
 
2011, Vector Informatik GmbH 
Version: 2.0 
10 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 2-10  List of configured servers 
With add you specify port and server name 
 
Figure 2-11  Specify port and server name 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
11 / 22 
based on template version 4.5 





 Vector Product Activation  
 
3  Extend a License 
 
 
Info 
You only need instructions in this chapter in case your company maintains its own li-
  cense server for Vector products. 
 
 
3.1 
Extend a License against Local License Server 
To extend a license against a local license server, open the License Manager  and follow 
the instructions. 
Step 1 Right click on a license you want to extend. Select Extend from the context menu. 
 
Figure 3-1 
Select Extend a license  
 
 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
12 / 22 
based on template version 4.5 





 Vector Product Activation  
 
Step 2 Enter the new Expiration date of the license. The new Expiration date must not be 
earlier than the initial Expiration date. Press OK. Once the license has been correctly ex-
tended on your PC, you’ll see a respective message. You’re done. 
 
Figure 3-2 
Enter the new Expiration date 
 
 
Info 
The Expiration date, which can be entered, depends on the actual license model of 
  your Vector software. If the entered date should not be possible, there will be a 
message box advising what range can be used with your license/Activation ID. 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
13 / 22 
based on template version 4.5 





 Vector Product Activation  
 
4  Return a License 
4.1 
Return a License to Vector Activation Server 
4.1.1 
Return a License via Internet 
To return a license via Internet to the Vector activation server, open the License Manager 
and follow the instructions. 
Step 1 Right click on a license you want to return. Select Return from the context menu. 
 
Figure 4-1 
Select Return a license 
Step 2 For Request method, we recommend using by Internet connection if you have 
Internet access (should you trust Vector software to connect to the Internet? See chapter 3 
Extend a License). 
Confirm with OK. Once the license has been successfully transferred back to the server, 
you’ll see a respective message. You’re done. 
 
 
 
Info 
In case a HTTP proxy is present in your network that requires a password and/or a log-
  in you will be prompted for that data. 
 
 
 
4.1.2 
Return a License via E-mail 
To return a license via e-mail, open the License Manager and follow the instructions. (only 
recommended if returning via Internet doesn't work). 
Step 1 Click on a license you want to return. Select Return from the context menu. 
2011, Vector Informatik GmbH 
Version: 2.0 
14 / 22 
based on template version 4.5 





 Vector Product Activation  
 
Step 2 For Request method, select Send request by e-mail. Continue and save the re-
quest as a file to any location on your hard disk. This file is the only proof of returning the 
license. Please keep this file carefully. 
Step 3 A new e-mail with the saved file as attachment is automatically opened. If this fails, 
attach the file manually to a new e-mail. 
Step  4  Send this e-mail to Vector (activation@vector-worldwide.com). No special subject 
or formatting of your e-mail is required. 
Step 5 If you then received a confirmation via e-mail from Vector, you can install and acti-
vate the Vector product on your new PC. 
4.2 
Return a License to a Local License Server 
 
 
Info 
You only need instructions in this chapter in case your company maintains its own 
  license server for Vector products. 
 
 
To return a license to a local license server, open the License Manager and follow these 
instructions: 
Step 1 Click on a license you want to return. Select Return from the context menu. 
Step  2  Enter the return ID and the server URL. The return token has the format R-
xxxxxxxxxxxxx-xxxxxxxxxxxxx with the first part equal to the activation ID. The server URL 
can be obtained from the drop down box. 
 
Figure 4-2 
Return license… 
Step 3 Ensure that you typed in the Return ID correctly. Press OK. Once the license has 
been successfully transferred back to the server, you’ll see a respective message. You’re 
done. 
2011, Vector Informatik GmbH 
Version: 2.0 
15 / 22 
based on template version 4.5 




 Vector Product Activation  
 
5  Repair Licenses 
It’s possible for several reasons that licenses are broken, i.e. invalid licenses. In this case 
all licenses for one type of server (Vector activation server or local license server) can be 
repaired at once. 
5.1 
Repair Licenses against Vector Activation Server 
The License Manger displays licenses which are broken with a warning sign. Licenses get 
into the status “broken” when e.g. the hard disk is broken and the Trusted Storage has to 
be restored from a backup. 
 
Figure 5-1 
License for repair 
To repair all licenses activated from the Vector activation server via Internet, open the Li-
cense Manager and follow the instructions. 
Step 1: Select License Keys / Repair Licenses / Vector Activation Server in the main 
menu of the License Manager. 
2011, Vector Informatik GmbH 
Version: 2.0 
16 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 5-2 
Select Repair licenses via Vector Activation Server 
Step 2 For Request method, we recommend using by Internet connection if you have 
Internet access (should you trust Vector software to connect to the Internet? See chapter 3 
Extend a License)
 
Figure 5-3 
Select request mode 
 
Confirm with OK. The license has been successfully repaired; you’ll see a respective mes-
sage. You’re done. 
5.1.1 
Repair a License via E-mail 
To repair all licenses of the Vector activation server via e-mail (only recommended if repair-
ing via Internet doesn't work), open the License Manager and follow the instructions: 
2011, Vector Informatik GmbH 
Version: 2.0 
17 / 22 
based on template version 4.5 




 Vector Product Activation  
 
Step 1 Select  License Keys  /  Repair Licenses / Vector Activation Server  in  the entry 
screen of the License Manager. 
Step 2 For request method select send request by e-mail. 
Step 3 Save the request as a file to any location on your hard disk using Save as…. 
 
Figure 5-4 
Save and send request 
Step 4 Press Open e-mail… to automatically open a new e-mail with the saved file as at-
tachment. If this fails, attach the file manually to a new e-mail. 
Step  5  Send this e-mail to Vector (activation@vector-worldwide.com). No special subject 
or formatting of your e-mail is required. 
Step 6 Press OK to close the dialog. 
Step 7 If you then received a certificate via e-mail from Vector, save the certificate from the 
e-mail as a file to any location on your hard disk. Then open the License Manager again.  
Step 8 Select License Keys / Continue e-mail transaction
2011, Vector Informatik GmbH 
Version: 2.0 
18 / 22 
based on template version 4.5 





 Vector Product Activation  
 
 
Figure 5-5 
Continue e-mail transaction 
Step 9 In the “Loading the certificate” dialog, press button Load certificate… and select 
the certificate file stored on your hard disk (in step 9). Continue. Once the licenses have 
been successfully repaired, you’ll see a respective message. You’re done. 
 
Figure 5-6 
Load certificate 
2011, Vector Informatik GmbH 
Version: 2.0 
19 / 22 
based on template version 4.5 





 Vector Product Activation  
 
5.2 Repair a License against a Local License Server 
To repair all licenses activated from a local license server, open the License Manager and 
follow the instructions. 
Step 1 Select License Keys / Repair Licenses / Local License Server in the main menu 
of the License Manager. 
 
Figure 5-7 
Repair licenses against local server 
Step 2  Enter local server name  and press OK  …  (see remarks at step 3/chapter  2.2 for 
server URL format). Once the licenses have been successfully repaired, you’ll see a re-
spective message. You’re done. 
 
Figure 5-8 
Repair licenses 
2011, Vector Informatik GmbH 
Version: 2.0 
20 / 22 
based on template version 4.5 








 Vector Product Activation  
 
6  FAQs and Background Information 
 
 
FAQ 
What options do I have if activation via Internet fails?
 
  Check your proxy settings and retry activation via Internet. If it continues to fail, use 
activation via e-mail. 
 
 
 
 
 
FAQ 
What options do I have if activation via e-mail fails? 

  Maybe you want to try direct activation via Internet – it is more convenient (see above). 
Otherwise please contact Vector (activation@vector-worldwide.com) with a detailed 
description of your actions and what happened. 
 
 
 
 
 
FAQ 
Should I trust Vector software to directly connect to the Internet? 

  Yes. In the product activation process, only data relevant to the installation are 
transferred. Vector uses the acquired data exclusively for product activation. Vector 
uses a wide-spread third-party product for implementing product activation, Acresso 
FLEXnet (former Macrovision FLEXlm). 
 
 
 
 
 
FAQ 
My hard-disk crashed. How do I get a license for my new PC? 

  Please contact Vector (activation@vector-worldwide.com). 
 
 
 
 
 
FAQ 
I get a new PC. How do I move my license from the old to the new PC?
 
  In Please contact Vector (activation@vector-worldwide.com). 
 
 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
21 / 22 
based on template version 4.5 



 Vector Product Activation  
 
7  Contact 
Visit our website for more information on 
 
>  News 
>  Products 
>  Demo software 
>  Support 
>  Training data 
>  Addresses 
 
www.vector.com 
2011, Vector Informatik GmbH 
Version: 2.0 
22 / 22 
based on template version 4.5 

Document Outline


15 - TechnicalReference_AutoConnect

Auto-Connect Port Prototypes

17 - TechnicalReference_AutoConnects

 
 
 
 
 
 
 
 
 
 
 
 
Auto-Connect Port Prototypes 
Technical Reference 
 
  
Version 1.0 
 
 
 
 
 
 
 
 
 
 
Authors 
Pavol Gramblicka 
Status 
Released 
 
 
 
 
 
 

Technical Reference Auto-Connect Port Prototypes 
Document Information 
History 
Author 
Date 
Version 
Remarks 
Pavol Gramblicka 
2015-04-28 
0.1.0 
Initial version 
Pavol Gramblicka 
2015-04-28 
1.0.0 
Final version 
 
2015, Vector Informatik GmbH 
Version: 1.0 
2 / 13 
based on template version 5.2.0 

Technical Reference Auto-Connect Port Prototypes 
Contents 
1 
Overview ....................................................................................................................... 5 
1.1 

Intended Audience ............................................................................................. 5 
1.2 
Terms and Acronyms ......................................................................................... 5 
2 
Input Port Prototypes ................................................................................................... 6 
3 
Auto-Connect ................................................................................................................ 7 
3.1 

Auto-Connect – simple pattern ........................................................................... 7 
3.2 
Auto-Connect – enhanced patterns .................................................................... 9 
3.2.1 

Prefix, Postfix ..................................................................................... 9 
3.2.2 
Complex patterns using the component prototype name .................. 10 
4 
Contact ........................................................................................................................ 13 
 
2015, Vector Informatik GmbH 
Version: 1.0 
3 / 13 
based on template version 5.2.0 

Technical Reference Auto-Connect Port Prototypes 
Illustrations 
Figure 2-1 
Start the contextless auto-connecting ......................................................... 6 
Figure 2-2 
Start the context dependent auto-connecting .............................................. 6 
Figure 3-1 
Simple auto-connect scenario ..................................................................... 7 
Figure 3-2 
List of proposed connections ...................................................................... 8 
Figure 3-3 
Context dependent auto-connecting of a prefixed port prototype ................ 9 
Figure 3-4 
Context dependent auto-connecting with a prefixed naming  pattern ........ 10 
Figure 3-5 
Context dependent auto-connecting of a port prototype without the 
component restriction ............................................................................... 11 

Figure 3-6 
Context dependent auto-connecting of port prototypes with the 
component restriction ............................................................................... 12 

 
Tables 
Table 1-1  
Terms and Acronyms .................................................................................. 5 
 
2015, Vector Informatik GmbH 
Version: 1.0 
4 / 13 
based on template version 5.2.0 

Technical Reference Auto-Connect Port Prototypes 
1  Overview 
DaVinci Developer is part of Vector’s solution for AUTOSAR compatible software design. It 
is  used  to  design  and  configure  software  components  and  provides  various  concepts  to 
support this process. 
This document describes a part of the design process related to DaVinci Developer from a 
technical  point  of  view,  trying  to  give  the  user  a  better  understanding  of  the  internal 
processes and how the tool reacts in different situations. 
1.1 
 Intended Audience 
This document aims at developers who are involved in the AUTOSAR design process and 
use DaVinci Developer to integrate various software components. 
1.2 
Terms and Acronyms 
Term 
Definition 
DEV 
DaVinci Developer 
Table 1-1   Terms and Acronyms 
2015, Vector Informatik GmbH 
Version: 1.0 
5 / 13 
based on template version 5.2.0 



Technical Reference Auto-Connect Port Prototypes 
2  Input Port Prototypes 
The  auto-connect  functionality  may  be  started  contextless  from  the  Software  Design 
toolbar (Figure 2-1) or from the context menu of the graphic view (Figure 2-2). 
 
Figure 2-1  Start the contextless auto-connecting 
 
Figure 2-2  Start the context dependent auto-connecting 
1.  In case of the contextless connecting, all port prototypes of the parent composition are 
considered. 
2.  In case of the context dependent connecting, the connections are created according to 
the provided selection. 
>  no selection – all port prototypes within the composition are considered 
>  a component is selected – all port prototypes of the component are considered 
>  single port prototype selection – only these port prototypes are considered to 
be the source resp. destination of a proposed connector prototype 
2015, Vector Informatik GmbH 
Version: 1.0 
6 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
3  Auto-Connect 
3.1 
Auto-Connect – simple pattern 
 
Figure 3-1  Simple auto-connect scenario   
 
Imagine  we  want  to  use  the  context  dependent  auto-connect  for  the  port  prototype 
Counter of the component SWC1. 
1.  Select the port prototype 
2.  Right mouse-click on port prototype to open the context menu 
3.  Choose Complete Connectors 
2015, Vector Informatik GmbH 
Version: 1.0 
7 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
 
Figure 3-2  List of proposed connections 
The algorithm is looking for counterparts for the selected port prototype SWC1.Counter 
>  in the first step, the naming pattern is analyzed to provide a key string 
>  simple pattern without prefix resp. postfix is used i.e. only the name of the port 
prototype is essential for the search algorithm, key string = Counter 
>  for all connectable port prototypesi, if the key string is a substring of the name of a 
connectable port prototype a connection will be proposed 
>  a line in the dialog then corresponds to the proposed connection 
>  additionally the algorithm can be refined with Connect Options 
>  Match case – consider case sensitive matching 
>  Match whole word – consider exact matching 
>  Allow split – in case of a P-Port more than one connection is allowed 
>  Allow merge – in case of an R-Port more than one connection is allowed 
>  Allow incompatible – consider AUTOSAR compatibility rules 
>  If you refined the options, press Apply to take the changes into account 
>  to get more information about proposed connection press right mouse button to open 
the context menu 
>  with Show P-Port resp. Show Connected menu buttons the port prototypes might 
be located in the software design 
>  with Add and Remove menu buttons the proposed list might be edited 
>  with the rest menu buttons the property dialogs might be open 
2015, Vector Informatik GmbH 
Version: 1.0 
8 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
3.2 
Auto-Connect – enhanced patterns 
In a more complicated case, the naming pattern of the selected port prototype has to be 
identified. 
3.2.1 
Prefix, Postfix 
Consider  the  designer  uses  always  a  prefix  or  a  postfix  for  his  port  prototypes,  e.g. 
SWC1::PPCounter. In this case, the algorithm cannot find any connectable port prototype 
which includes the substring PPCounter in his name. 
 
Figure 3-3  Context dependent auto-connecting of a prefixed port prototype 
The  user must  explicitly  determinate the  prefix  part. When  computing  the  key  string,  the 
prefix part will be removed and the algorithm is running like in the simple case. 
2015, Vector Informatik GmbH 
Version: 1.0 
9 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
 
Figure 3-4  Context dependent auto-connecting with a prefixed naming  pattern 
3.2.2 
Complex patterns using the component prototype name 
In a very special case, the destination component may be identified by the naming pattern. 
This  scenario  is  applicable  if  there  are  components  which  have  port  prototypes  of  the 
same  or  similar  naming  but  the  proposed  set  should  be  restricted  to  a  dedicated 
component.  Suppose  we  want  to  restrict  the  proposal  to  component  SWC2.  The  Figure 
3-5 
displays such a scenario where connections to SWC2 and SWC3 will be proposed. In 
our  example,  we  can  simply  remove  the  connection  to  SWC3  but  in  general  it  might  be 
difficult to identify such relations. 
 
2015, Vector Informatik GmbH 
Version: 1.0 
10 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
 
Figure 3-5  Context dependent auto-connecting of a port prototype without the component restriction 
To  be  sure  the  port  prototype  of  the  desired  component  will  be  proposed,  the  restriction 
must be coded in the name of the selected port prototyped. The naming pattern looks like 
this <COMPONENT_PROTOTYPE>_<PORT_PROTOTYPE>. The algorithm will parse the 
port  prototype  name  and  try  to  identify  corresponding  parts.  Additionally  to  the  current 
concept, the name of the component will be matching. 
2015, Vector Informatik GmbH 
Version: 1.0 
11 / 13 
based on template version 5.2.0 


Technical Reference Auto-Connect Port Prototypes 
 
Figure 3-6  Context dependent auto-connecting of port prototypes with the component restriction 
 
2015, Vector Informatik GmbH 
Version: 1.0 
12 / 13 
based on template version 5.2.0 

Technical Reference Auto-Connect Port Prototypes 
4  Contact 
Visit our website for more information on 
 
>  News 
>  Products 
>  Demo software 
>  Support 
>  Training data 
>  Addresses 
 
www.vector.com 
                                            
iA connectable port prototype is such a port prototype which allow for creation of a meaningful connector 
prototypes. In case of an assembly connector, if P-Port is selected only an R-Port or PR-Ports are 
meaningful and vice versa. In case of a delegation connector prototypes, if P-Port is selected only a P-Port 
or PR-Port are meaningful and similar if an R-Port is selected only an R-Port or PR-Port are meaningful. 
2015, Vector Informatik GmbH 
Version: 1.0 
13 / 13 
based on template version 5.2.0 

Document Outline


18 - TechnicalReference_DataTypes_AR4

Autosar 4.0 - DataTypes

20 - TechnicalReference_DataTypes_AR4s

Technical Reference Autosar 4.0 - DataTypes 
 
 
 
 
 
 
 
 
 
 
 
Autosar 4.0 - DataTypes 
Technical Reference 
 
 
Version 1.1 
 
 
 
 
 
 
 
 
 
 
Authors 
Thomas Bruni 
Status 
Released 
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
1 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
Document Information 
History 
Author 
Date 
Version 
Remarks 
Thomas Bruni 
11.11.2013 
0.1 
Document creation 
Thomas Bruni 
14.01.2014 
0.2 
Changes: 
3.4 Platform types 
 
Thomas Bruni 
27.01.2014 
0.3 
Corrections  in  3.4  Platform 
types 
Thomas Bruni 
29.01.2014 
0.4 
Creation  of  2  new  chapters: 
3.4 Data type mapping 
5.4  Data  type  mapping 
assistant 
5.5 Type emitter 
Thomas Bruni 
21.02.2014 
1.0 
Release version 
Thomas Bruni 
14.03.2014 
1.1 
Changes 
for 
Mode 
Declaration  Group  mapping: 
chapters 3.4 and 4.4. 
Reference Documents 
No. 
Source 
Title 
Version 
[1]   
AUTOSAR  AUTOSAR_TPS_SoftwareComponentTemplate 
4.2.0 
[2]   
AUTOSAR  AUTOSAR_SWS_PlatformTypes 
2.5.0 
 
2014, Vector Informatik GmbH 
Version: 1.1 
2 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
Contents 
1  Introduction .................................................................................................................... 6 
2  Data Types and Data Prototypes ................................................................................... 7 
3  Design of data prototypes in DaVinci tool chain .......................................................... 8 
3.1  Data prototypes ........................................................................................................ 8 
3.2  Application data types ............................................................................................ 10 
3.3  Implementation data types ..................................................................................... 11 
3.4  Data type mapping ................................................................................................. 14 
3.5  Platform types ........................................................................................................ 15 
3.5.1 
Definitions ..................................................................................................... 15 
3.5.1.1 
Autosar Standard Types ......................................................................... 15 
3.5.1.2 
Platform Types ....................................................................................... 15 
3.5.1.3 
Valid C expression .................................................................................. 15 
3.5.2 
Practice ......................................................................................................... 16 
3.5.2.1 
Abstraction of SW from platform ............................................................. 16 
3.5.2.2 
Dependency between SW and platform ................................................. 17 
3.5.2.3 
Platform types and Vector DaVinci Tool suite .......................................... 18 
3.6  Generation ............................................................................................................. 22 
4  Design examples .......................................................................................................... 23 
4.1  Primitive data element ............................................................................................ 23 
4.2  Complex data element ........................................................................................... 36 
4.3  Enumeration ........................................................................................................... 48 
4.3.1 
Application level ............................................................................................ 48 
4.3.2 
Implementation level ..................................................................................... 52 
4.4  Mode declaration .................................................................................................... 55 
4.4.1 
Mode declaration group in DaVinci Developer ............................................... 55 
4.4.2 
Mode service port in BswM configuration ...................................................... 59 
4.4.3 
Mode request port and mapping .................................................................... 62 
4.5  Implementation data type examples ....................................................................... 66 
4.5.1 
Type reference .............................................................................................. 66 
4.5.2 
Value ............................................................................................................. 67 
5  Additional information ................................................................................................. 69 
5.1  Compatibility and conversion .................................................................................. 69 
5.2  Measurement and calibration ................................................................................. 70 
5.3  Symbols ................................................................................................................. 72 
5.4  Data type mapping assistant .................................................................................. 73 
2014, Vector Informatik GmbH 
Version: 1.1 
3 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
5.5  Type emitter ........................................................................................................... 78 
6  Glossary and Abbreviations ........................................................................................ 79 
6.1  Glossary ................................................................................................................. 79 
6.2  Abbreviations ......................................................................................................... 79 

7  Contact.......................................................................................................................... 80 
 
Illustrations 
Figure 3-1 
S/R port interface element .......................................................................... 9 
Figure 3-2 
S/R port interface element init value ........................................................... 9 
Figure 3-3 
DaVinci Developer – workspace library ..................................................... 10 
Figure 3-4 
Application data type categories ............................................................... 10 
Figure 3-5 
Application data type Value property dialog .............................................. 11 
Figure 3-6 
Implementation data type categories ........................................................ 12 
Figure 3-7 
Implementation data type Value property dialog ....................................... 13 
Figure 3-8 
2 ways of modelling platform independent implementation data types ...... 17 
Figure 3-9 
Modelling a platform specific implementation data type ............................ 18 
Figure 3-10 
Platform Types in DaVinci Developer ........................................................ 19 
Figure 3-11 
Implementation data type referencing a platform type ............................... 19 
Figure 3-12 
Native declaration: Autosar Standard Type ............................................... 20 
Figure 3-13 
Native declaration: valid C expression ...................................................... 21 
Figure 4-1 
New Value application data type ............................................................... 24 
Figure 4-2 
My_TemperatureType ............................................................................... 25 
Figure 4-3 
My_TemperatureType_CompuMethod ...................................................... 25 
Figure 4-4 
Celsius unit ............................................................................................... 26 
Figure 4-5 
Physical to Internal linear scale ................................................................ 26 
Figure 4-6 
Physical constraint .................................................................................... 27 
Figure 4-7 
Type mapping set creation ........................................................................ 28 
Figure 4-8 
Type mapping set naming ......................................................................... 28 
Figure 4-9 
Add a data type mapping to a type mapping set ....................................... 29 
Figure 4-10 
My_TemperatureInterface ......................................................................... 30 
Figure 4-11 
My_TemperatureElement .......................................................................... 30 
Figure 4-12 
SWC_Sender modeling ............................................................................ 31 
Figure 4-13 
SWC_Receiver modeling .......................................................................... 32 
Figure 4-14 
Connection of My_TemperatureInterface ports ......................................... 33 
Figure 4-15 
Missing data type mapping error message ............................................... 33 
Figure 4-16 
Reference a type mapping set in a SWC .................................................. 34 
Figure 4-17 
My_SpeedType settings ........................................................................... 36 
Figure 4-18 
New Record application data type ............................................................ 37 
Figure 4-19 
Record type creation with 2 record elements ............................................ 38 
Figure 4-20 
New Record implementation data type ..................................................... 39 
Figure 4-21 
Set a record implementation data type...................................................... 40 
Figure 4-22 
Record type mapping ................................................................................ 41 
Figure 4-23 
Sender/receiver port interface with record element ................................... 42 
Figure 4-24 
Record manual init – part 1 ....................................................................... 43 
Figure 4-25 
Record manual init – part 2 ....................................................................... 44 
Figure 4-26 
Record constant creation .......................................................................... 45 
Figure 4-27 
Referencing a record constant as init value .............................................. 46 
Figure 4-28 
My_RecordInterface port connection ........................................................ 46 
2014, Vector Informatik GmbH 
Version: 1.1 
4 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
Figure 4-29 
My_Enumeration type ............................................................................... 48 
Figure 4-30 
My_EnumerationType_CompuMethod ...................................................... 49 
Figure 4-31 
Enumeration text table setting .................................................................. 49 
Figure 4-32 
Enumeration constraint ............................................................................. 50 
Figure 4-33 
My_Enumeration mapping to uint8 ........................................................... 50 
Figure 4-34 
“My_EnumerationInterface” ...................................................................... 50 
Figure 4-35 
My_EnumerationImplType ........................................................................ 52 
Figure 4-36 
My_EnumerationImplType_CompuMethod ............................................... 52 
Figure 4-37 
My_EnumerationImplType_CompuMethod text table ................................ 53 
Figure 4-38 
My_EnumerationImplInterface .................................................................. 53 
Figure 4-39 
New mode declaration group .................................................................... 55 
Figure 4-40 
My_ModeDeclarationGroup ...................................................................... 56 
Figure 4-41  
My ModePortInterface .............................................................................. 56 
Figure 4-42 
Mode ports connection ............................................................................. 57 
Figure 4-43 
Mode port access ..................................................................................... 57 
Figure 4-44 
BswM configuration .................................................................................. 59 
Figure 4-45 
BswM import in DaVinci Developer ........................................................... 59 
Figure 4-46 
Mode declaration group import in DaVinci Developer ............................... 60 
Figure 4-47 
ComM mode declaration group ................................................................. 60 
Figure 4-48 
My_ModeDeclarationGroup ...................................................................... 62 
Figure 4-49 
My_ModeDeclarationGroup_IType ........................................................... 63 
Figure 4-50 
Mode declaration group mapping.............................................................. 63 
Figure 4-51 
My_ModeRequestInterface ....................................................................... 64 
Figure 4-52 
My_ModeRequestPort .............................................................................. 64 
Figure 4-53 
Type mapping set reference for mode request .......................................... 64 
Figure 4-54 
New type reference................................................................................... 66 
Figure 4-55 
Value implementation data type ................................................................ 67 
Figure 4-56 
My_ImplValue_base base type ................................................................. 68 
Figure 4-57 
Implementation type constraint ................................................................. 68 
Figure 5-1 
Info Message #40286 ............................................................................... 69 
Figure 5-2 
Rte configuration for A2L generation ......................................................... 70 
Figure 5-3 
A2L generation folder................................................................................ 70 
Figure 5-4 
Symbol field for implementation data type ................................................ 72 
Figure 5-5 
Data type mapping assistant opening ....................................................... 73 
Figure 5-6 
Data type mapping assistant ..................................................................... 73 
Figure 5-7 
New mapping............................................................................................ 75 
Figure 5-8 
Existing mapping ...................................................................................... 75 
Figure 5-9 
Created after new mapping ....................................................................... 76 
Figure 5-10 
New mapping with implementation data type creation .............................. 76 
Figure 5-11 
Existing mapping with implementation data type creation ......................... 77 
Figure 5-12 
Created after new mapping with implementation data type creation ......... 77 
 
2014, Vector Informatik GmbH 
Version: 1.1 
5 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
1  Introduction 
This technical reference aims at presenting Data Type modeling with Vector DaVinci tool 
chain in Autosar 4.0.3 context. 
   
2014, Vector Informatik GmbH 
Version: 1.1 
6 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
2  Data Types and Data Prototypes 
Embedded  software  uses  data  elements,  which  are  entities  containing  information 
computed by algorithms, carried between application blocks, used as reference value, etc. 
Data  elements  are  designed  according  to  the  information  they  need  to  represent.  The 
structure definition of a data element is called data type. 
In Autosar  specification (see  [1])  data elements  are  called data prototypes because they 
are  the  prototype  or  the  instance  of  a  certain  data  type  that  they  reference.  Data 
prototypes  can  be  variable  elements  of  a  sender/receiver  port  interface,  operation 
arguments  of  a  client/server  interface,  modes  of  a  mode  switch  interface,  calibration 
parameters, per instance memory parameters, inter-runnable variables, etc. 
Data  prototypes  may  have  different  levels  of  representation.  They  may  have  a  physical 
meaning,  like  speed  information,  or  temperature  information.  They  also  must  have  an 
internal meaning which is used at code level, like 8 bit integer, or Boolean. 
In  order  to  carry  these  different  levels  of  representation Autosar defines  application  data 
types  and  implementation  data  types.  Application  data  types  define  data  structure 
corresponding to the physical world. Implementation data types define data structure used 
in embedded code. 
For  a  data  prototype  the  application  data  type  level  is  optional,  whereas  the 
implementation  data  type  level  is  mandatory.  Autosar  allows  2  ways  of  modeling  data 
prototypes: 
 
  With a reference to an application data type: 
In  case  a  data  prototype  has  a  physical  meaning,  it  shall  reference  an  application  data 
type. In that case, in order to also define the structure of the data prototype at code level, 
the  application  data  type  must  be  mapped  to  an  implementation  data  type  in  a  type 
mapping set. 
 
  With a reference to an implementation data type: 
If a data prototype does not have any physical meaning, it is possible to reference directly 
an implementation data type. 
 
 
 
Note 
During  the  design  phase  of  a  project,  the  architect  models  the  data  prototypes  and 
  maps them to data types. According to Autosar philosophy it is recommended to use as 
much  application  data  types  as  possible  and  to  reuse  implementation  data  types  in 
data  type  mapping.  It  allows  staying  at  application  level  during  design  and  avoids 
creating too many implementation data types in the code.  
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
7 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
3  Design of data prototypes in DaVinci tool chain 
Design is realized in  DaVinci Developer.  In the following  chapters,  figures and examples 
are presented from DaVinci Developer version 3.5.19 (SP1) and MICROSAR RTE 4.01.01. 
 
3.1 
Data prototypes 
 
Data  prototypes  take  several  different  forms  in  an  Autosar  ECU  project.  It  can  be  an 
element of a sender/receiver interface, an argument of a client/server interface operation, 
an  inter-runnable  variable,  a  per-instance-memory  variable,  a  calibration  parameter…  In 
general  a  data  prototype  contains  the  following  attributes  (see  Figure  3-1  with  S/R 
interface element example): 
 
-  Reference to an application data type or implementation data type: 
This reference defines the type of the data element. 
In  case  an  application  data  type  is  chosen,  this  application  data  type  must  be 
mapped  to  an  implementation  data  type  in  a  type  mapping  set. This  mapping  set 
must be referenced by the application SWCs, which are using the data element. 
In  case  an  implementation  data  type  is  chosen,  no  mapping  is  necessary.  The 
implementation data type will be used in the code as type of the data element. 
 
-  Measurement and calibration access: 
In  case  the  data  element  is  intended  to  be  accessed  via  measurement  and 
calibration, the access type (ReadOnly or ReadWrite) shall be set here. 
If no access is necessary, NotAccessible shall be set. 
 
-  Init value (not for per-instance-memory and not for operation arguments): 
The init value field defines the initial value that the data element will take at startup 
of the software execution. 
 
 
 
Note 
The init value of a sender/receiver interface element is defined in the Com spec of each 
  port prototype referencing the interface (see Figure 3-2)
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
8 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
-  Invalid value handling (for sender/receiver interface elements): 
It is possible to specify how invalid value shall be handled: 
o  None: no specific handling is defined 
o  Keep:  an  invalidate  function  is  provided  by  the  Rte  to  the  SWCs  that  are 
sending the data element. The SWCs can report that the value is invalid by 
calling this function. The invalid value is kept, and a flag is set to inform the 
receivers that the value is invalid. 
o  Replace: an invalidate function is provided by the Rte to the SWCs that are 
sending the data element. The SWCs can report that the value is invalid by 
calling this function. The invalid value is replaced by the init value.   
 
-  Data constraints (for server/receiver interface elements): 
o  It is possible to define data constraints at data element level. 
 
 
Figure 3-1  S/R port interface element 
 
 
Figure 3-2  S/R port interface element init value 
2014, Vector Informatik GmbH 
Version: 1.1 
9 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
3.2 
Application data types 
 
In DaVinci Developer tool, it is possible to create application data types in the “Data Types” 
library under “Application Data Types” (see Figure 3-3). 
 
 
Figure 3-3  DaVinci Developer – workspace library 
It is possible to choose the application data type category among  Boolean, Value, String, 
Array and Record (see Figure 3-4)
 
Figure 3-4  Application data type categories 
An  application  data  type  contains  several  attributes  (see  Figure  3-5  a  Value  category 
example): 
 
-  Compu Method:  
The  computation  method  defines  the  conversion  from  internal  representation  to 
physical representation, in other words from code perspective to physical meaning.  
It  is  possible  to  define  linear,  scale-linear,  text  table,  scale-linear  &  text  table 
conversions from internal to physical and/or from physical to internal. 
 
-  Unit: 
The unit instance defines the physical unit.  
2014, Vector Informatik GmbH 
Version: 1.1 
10 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
Note 
If  a  Compu  Method  is  provided,  it  is  recommended  to  set  the  unit  in  the  Compu 
  Method.  If  no  Compu  Method  is  provided,  the  unit  can  be  entered  directly  in  the 
application data type property dialog. 
 
 
-  Constraint: 
With a constraint instance it is possible to define the internal and/or physical valid 
range of data values.  
 
-  Invalid value: 
An invalid value may be defined. It however has no impact on the code. It is only set 
as information in DaVinci Developer. To invalidate a data element value, the sender 
SWC must call the invalidate function provided by the Rte. 
 
 
Figure 3-5  Application data type Value property dialog 
More details and examples are presented in chapter 4. 
 
3.3 
Implementation data types 
 
In DaVinci Developer tool  it is possible to create implementation data types in  the “Data 
Types” library under “Implementation Data Types” (see Figure 3-3). 
 
It  is  possible  to  choose  the  implementation  data  type  category  among  Value,  Type 
Reference, Data Reference, Array and Record (see Figure 3-6). 
2014, Vector Informatik GmbH 
Version: 1.1 
11 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 3-6  Implementation data type categories 
An  implementation  data  type  contains  several  attributes  (see  Figure  3-7  with  a  Value 
category example): 
 
-  Base type reference: 
o  This  reference  must  be  provided  in  implementation  data  types  of  category 
Value in order to define the corresponding base type. 
o  Base types may be created manually in the “Data Types” library under “Base 
Types”.  
o  It  is  also  possible  to  link  the  implementation  data  type  to  an  existing 
implementation data type (e.g. to a platform type) by choosing the category 
Type Reference.  
 
 
 
 
Note 
In  case  a  new  implementation  data  type  is  based  on  a  type  that  does  not  exist,  the 
  designer may need to create a new base type.  
If an existing type corresponds to the need of the designer, it is recommended to create 
a Type  Reference  and  reference  an  existing  type.  In  particular  it  is  recommended  to 
reference the platform types (see chapter 3.5)
 
 
 
-  Compu method: 
It is possible to define a computation method in the implementation data type.  
 
 
Note 
As  defined  by  Autosar  the  compu  method  of  an  implementation  data  type  is  not 
  intended to provide any physical meaning (this is the role of application data type). For 
an  implementation  data  type,  only  TextTable  conversion  is  allowed  which  generates 
enumeration strings in the code that are used instead of the numerical value.  
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
12 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
-  Constraint: 
It is possible to define constraints at implementation level. 
 
 
 
Note 
A  constraint  at  implementation  level  will  be  used generally  to  define  the  valid internal 
  range. 
 
 
 
 
Figure 3-7  Implementation data type Value property dialog 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
13 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
3.4 
Data type mapping 
 
As  previously  written,  application  data  types  must  be  mapped  to  implementation  data 
types.  For  this  purpose  data  type  mapping  sets  containing  data  type  mappings  must  be 
created. Data type mappings contain two references, one to the application data type and 
one to the implementation data type. 
 
In  order  to  let  the  Rte  generator  access  the  right  data  type  mapping  for  each  data 
prototype needing a data type mapping, data type mapping sets must be referenced by the 
SWCs using the corresponding data prototypes. 
 
Mode  declaration  groups  may  also  be  mapped  to  implementation  data  types  in 
ModeRequestTypeMap  contained  also  in  data  type  mapping  sets.  The  purpose  of  this 
mapping is not the representation of the mode declaration group in the code because the 
type used in the code for mode declaration groups is generated automatically by the Rte 
generator  according  to  the  number  of  mode  declarations:  uint8  for  1  to  256  mode 
declarations, uint16 for 257 till  65536 mode declarations, and so on...  
The purpose of  a  ModeRequestTypeMap  is  to be able  to create mode request  ports. As 
specified  by Autosar  a  component  that  requests  mode  changes  to  a  mode  master  shall 
implement a sender/receiver P-Port on which the requests will be sent. The corresponding 
port interface’s data element shall be typed by an implementation data type referencing a 
compu  method  containing  an  enumeration  of  the  corresponding  modes.  That 
implementation data type shall be mapped to the corresponding mode declaration group.   
 
Examples are presented in chapter 4. 
 
2014, Vector Informatik GmbH 
Version: 1.1 
14 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
3.5 
Platform types 
 
3.5.1 
Definitions 
 
3.5.1.1 
Autosar Standard Types 
 
Autosar Standard Types are the following symbols used in C code: 
   
>  uint8 
>  uint16 
>  uint32 
>  sint8 
>  sint16 
>  sint32 
>  boolean 
>  float 
>  float32 
 
3.5.1.2 
Platform Types 
 
Platform  types  are  implementation  data  types  which  have  an Autosar  Standard  Type  as 
name. 
Platform types, as subset of implementation data types, are part of the model. 
 
3.5.1.3 
Valid C expression 
 
A valid C expression is a C type optionally combined to a C size qualifier and/or a C sign 
qualifier. 
 
>  C types are: char, int, float, double, void 
>  C size qualifiers are: short, long 
>  C sign qualifiers are: signed, unsigned 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
15 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
3.5.2 
Practice 
 
Implementation data types need to be generated in C code and represented at CPU level. 
For this purpose 2 ways can be followed: 
 
  With abstraction of SW from platform 
  With dependency between SW and platform 
 
3.5.2.1 
Abstraction of SW from platform 
 
This  way  of  representing  implementation  data  types  at  CPU  level  is  advised,  because  it 
follows the Autosar philosophy of independency between SW and platform. 
 
It consists in linking implementation data types to Platform Types, which are represented 
by Autosar Standard Types in C code. 
 
Each implementation data type shall finally be linked to Platform Types. This may be done 
in 2 ways: 
 
  The  implementation  data  type’s  name  is  an Autosar  Standard Type.  In  this  case  the 
implementation data type is implicitly the corresponding Platform Type. 
  The implementation data type references a Platform Type. The implementation data is 
in  this  case  of  category  “Type  Reference”  and  references  directly  an  implementation 
data type which is a Platform Type or which is referencing a Platform Type itself. 
Such a reference will generate a “typedef” where the implementation data type will be 
defined by the Autosar Standard Type. 
 
 
Example 
Implementation data type name: MyImplementationDataType 
  Platform Type name: uint8 
Generation: typedef uint8 MyImplementationDataType; 
 
 
 
As  defined  in  [2],  a  Platform_Types.h  file  must  be  integrated  into  the  project  and  shall 
contain the platform specific and/or compiler specific definition of Autosar Standard Types. 
In other words, this file contains a typedef for each Autosar Standard Type mapping it to a 
valid C expression. 
Platform_Types.h is thus the link between SW and platform which  are  independent from 
each other. 
2014, Vector Informatik GmbH 
Version: 1.1 
16 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
 
Note 
Platform_Types.h  also  contains  3  parameters  which  are  CPU  specific: 
  CPU_BIT_ORDER, to define bit alignment, CPU_BYTE_ORDER, to define Byte order, 
and CPU_TYPE, to define the processor bit length. 
 
 
Figure 3-8 summarizes these 2 ways of modelling: 
 
Figure 3-8  2 ways of modelling platform independent implementation data types 
 
 
3.5.2.2 
Dependency between SW and platform 
 
In a same way as for Complex Device Drivers, Autosar gives also the chance to break this 
abstraction by setting CPU and/or compiler specific information in base types: 
 
An  implementation  data  type  of  category  Value  must  reference  a  base  type,  which 
contains a native declaration parameter. Setting a valid C expression as native declaration 
will generate a typedef defining the implementation data type as this valid C expression in 
Rte_Type.h. 
 
In  this  way,  the  implementation  data  type  and  the  SWCs  using  this  implementation data 
type are platform specific. 
2014, Vector Informatik GmbH 
Version: 1.1 
17 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
Example 
Implementation data type name: MyImplementationDataType 
  Native declaration in base type: unsigned char 
Generation: typedef unsigned char MyImplementationDataType; 
 
 
 
Figure 3-9 summarizes this modelling: 
 
 
Figure 3-9  Modelling a platform specific implementation data type 
 
3.5.2.3 
Platform types and Vector DaVinci Tool suite 
 
Vector DaVinci Developer provides the Platform Types in the Implementation Data Types 
library at workspace creation (see Figure 3-10)
 
2014, Vector Informatik GmbH 
Version: 1.1 
18 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 3-10  Platform Types in DaVinci Developer 
 
According to Autosar it is advised to do the following: 
  Use directly Platform Types as implementation data types. 
  Create an own implementation data type of category  “Type Reference” referencing a 
Platform Type:  
Creating MyImplementationDataType as Type Reference pointing on uint8 (see Figure 
3-11) Pl
atform type will generate in Rte_Type.h:  
typedef uint8 MyImplementationDataType; 
 
 
Figure 3-11  Implementation data type referencing a platform type  
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
19 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
However other ways are possible: 
  It is possible to write the name of an Autosar Standard Type as native declaration in 
the  BaseType  referenced  by  MyImplementationDataType  of  category  Value  (see 
Figure 3-12). This way is however not very pretty because its intention is to model a 
“Type  Reference”  without  expressing  it  formally  in  the  model.  In  this  case  the  same 
typedef will be generated:  
typedef uint8 MyImplementationDataType; 
 
 
Figure 3-12  Native declaration: Autosar Standard Type 
 
  BaseType  with  C  native  declaration:  it  is  possible  to  generate  the  platform  specific 
definition  of  an  implementation  data  type  using  the  native  declaration  field.  In  the 
provided example (see Figure 3-13), the following will be generated: 
typedef unsigned char MyImplementationDataType; 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
20 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 3-13  Native declaration: valid C expression 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
21 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
3.6 
Generation 
 
The following is generated out of the data type design: 
 
-  In code: 
o  Implementation data types are provided in the generated code as typedef. 
o  From application data types are generated: 
  Init values: they are calculated from the init value and the computation 
method settings. 
  Lower and upper range limits as defines: they are calculated out of the 
constraint range and the computation method. 
  Invalid value handling: the way of treating invalid  values depends on 
the  handling  setting.  The  corresponding  invalidate  function  is 
implemented  in  the  Rte  and  provided  to  SWC  that  send  the 
corresponding data element.  
  Enumeration:  if  the  defined  computation  method  is  a  text  table,  an 
enumeration is provided. 
 
-  For measurement and calibration: 
o  An A2L file can be generated with data prototype access: 
  The read and write access is defined by the attribute specified at data 
element  level.  It  overrides  the  attribute  provided  in  application  or 
implementation data types. 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
22 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4  Design examples 
 
 
 
Caution 
Each ECU project is specific and has its own needs.  
  The examples presented in this chapter aim at showing how to use DaVinci Developer 
tool chain and what is generated out of the example configuration.  
Not all possible configurations are presented here, and it is up to the ECU designer to 
choose the appropriate configuration settings depending on the needs of the project. 
 
 
4.1 
Primitive data element 
 
This  example  shows  the  design  of  a  primitive  application  data  type  referenced  by  a 
sender/receiver port interface data element. 
 
A sender/receiver port interface is designed to send a temperature value in Celsius. 
The  physical  values  can  be  in  the  range  [-50°C;  +150°C]  with  0,5°C  resolution.  In  other 
words, the values can be -50°C, -49,5°,…, +149,5°C, +150°C. 
In order to model the values at code level, a type covering such a range shall be defined. 
In  this  case  it  is  necessary  to  cover  401  values.  An  8  bit  integer  will  not  be  sufficient 
because  it  covers  only  256  values. A  16  bit  integer  (uint16  or  sint16)  can  be  used. The 
conversion  function  will  be  adjusted  to  this  choice.  In  this  example  sint16  is  chosen.  A 
linear  conversion  from  physical  to  internal  with  factor  2  and  offset  0  (f(x)=2.x+0)  will  be 
used. The corresponding internal range will be [-100; +300]. 
 
  An application data type is created to model the physical part of the data type: 
 
>  Creation of a new Value application data type: 
>  Right  click  on  the  “Application  Data  Types”  library  is  done  and  “Value”  is  selected 
(see Figure 4-1). 
2014, Vector Informatik GmbH 
Version: 1.1 
23 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-1  New Value application data type 
>  The application data type attributes are filled (see Figure 4-1)
>  A name is given: “My_TemperatureType” 
>  A  computation  method  is  created:  “My_TemperatureType_CompuMethod”  (see 
Figure 4-3): 
  Category is set to linear 
  A  “Celsius”  unit  is  created  (see  Figure  4-4)  and  is  referenced  in  the 
compu method 
  “Physical to internal” conversion is chosen 
  The  physical  to  internal  linear  scale  is  configured  with  factor  2  and 
offset 0 over the physical range [-50;+150] (see Figure 4-5) 
 
>  A physical constraint is created: “My_TemperatureType_Contraint” (see Figure 4-6):  
  It defines the physical range with boundary inclusions: [-50;+150] 
 
 
 
 
Note 
The  physical  to  internal  conversion  is  also  used  for  internal  to  physical  conversion  in 
  case the defined function is invertible. It is the case in this example, so it is enough to 
specify only the physical to internal conversion. 
The  linear  conversion  factor  and  offset  are  used  in  the  following  way: 
With Xi representing the internal value and Xp the physical one. 

Physical to internal: factor Fp and offset Op: 
Xi = Fp.(Xp + Op) 

Internal to physical: factor Fi and offset Oi: 
Xp = Fi.Xi + Oi 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
24 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 4-2  My_TemperatureType 
 
 
Figure 4-3  My_TemperatureType_CompuMethod 
 
2014, Vector Informatik GmbH 
Version: 1.1 
25 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-4  Celsius unit 
 
 
Figure 4-5  Physical to Internal linear scale 
 
2014, Vector Informatik GmbH 
Version: 1.1 
26 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-6  Physical constraint 
 
  The internal part of the data type is modeled with the existing platform type sint16. 
 
It is thus not necessary to create a new implementation data type. 
 
  In order to finish the data type modeling, a data type mapping set has to be used to 
specify the mapping between “My_TemperatureType” and sint16. 
>  A new type mapping set is created: 
>  Right click on the Type Mapping Sets library is done and “New Type Mapping Set…” 
is selected (see Figure 4-7)
 
 
 
Note 
It  is  not  necessary  to  create  a  new  type  mapping  set  for  each  data  type  mapping.  A 
  single type mapping set can contain several data type mappings. 
It  is  even  recommended  to  gather  data  type  mappings  in  type  mapping  sets,  not  to 
have too many data type mapping set. 
 
 
 
>  A name is given to the type mapping set (see Figure 4-8)
>  The data type mapping is done in the “Data Type Maps” tab of the type mapping set 
property dialog (the steps are described Figure 4-9) 
 
2014, Vector Informatik GmbH 
Version: 1.1 
27 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-7  Type mapping set creation 
 
Figure 4-8  Type mapping set naming 
2014, Vector Informatik GmbH 
Version: 1.1 
28 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-9  Add a data type mapping to a type mapping set 
2014, Vector Informatik GmbH 
Version: 1.1 
29 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
 
 
 
Note 
In the Data Type Map dialog a check box is available to filter only the compatible data 
  types. It is checked by default. 
 
 
 
  Now that the data type for the temperature data elements is modeled, it can be used. 
 
In this example a sender/receiver port interface containing a temperature data element is 
designed. The port interface “My_TemperatureInterface” is created (see  Figure 4-10) and 
“My_TemperatureElement” is created inside (see Figure 4-11). 
 
 
Figure 4-10  My_TemperatureInterface 
 
 
Figure 4-11  My_TemperatureElement 
2014, Vector Informatik GmbH 
Version: 1.1 
30 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
Two  SWCs  implementing  port  prototypes  referencing  this  port  interface  are  created. 
SWC_Sender  is  writing  “My_TemperatureElement”  in  “SWC_SenderRunnable”  and 
“SWC_Receiver”  is  reading  it  in  “SWC_ReceiverRunnable”  (see  Figure  4-12  and  Figure 
4-13)
. The init value on both sides is set to 20. 
 
Figure 4-12  SWC_Sender modeling 
2014, Vector Informatik GmbH 
Version: 1.1 
31 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-13  SWC_Receiver modeling 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
32 / 80 
based on template version 5.1.0 





Technical Reference Autosar 4.0 - DataTypes 
Both ports are connected via a SWConnector in the graphical editor (see Figure 4-14). 
 
Figure 4-14  Connection of My_TemperatureInterface ports 
If the configuration is left like this a “missing data type mapping” error message will appear 
(see Figure 4-15). It is due to the fact that at SWC level “My_TemperatureElement”, typed 
by the application data type “My_TemperatureType”, is not mapped to any implementation 
data type. Even if the mapping was realized in “My_TypeMappingSet”, this mapping is not 
known by the SWCs until it is explicitly referenced. 
 
 
Figure 4-15  Missing data type mapping error message 
Each  SWC using a  data element,  typed  by  an  application  data  type,  must  reference  the 
corresponding  type  mapping  set,  where  the  corresponding  implementation  data  type  is 
specified. 
“My_TypeMappingSet” shall be referenced in  SWC_Sender and SWC_Receiver property 
dialog (see Figure 4-16). 
 
 
 
Note 
It is possible to reference several type mapping sets in a same SWC. 
 
 
 
 
 
Note 
If the project requires a different mapping depending on a certain context, it is possible 
  to  map  the  same  application  data  type  to  different  implementation  data  types  using 
several type mapping sets. 
For instance it could be possible to map “My_TemperatureType” to sint32 in a second 
type mapping set, which could be used by 2 other SWCs. In the context of these 2 new 
SWCs “My_TemperatureType” would be mapped to sint32. 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
33 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-16  Reference a type mapping set in a SWC 
2014, Vector Informatik GmbH 
Version: 1.1 
34 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
  The system description resulting from the configuration done in DaVinci Developer is 
imported  in  DaVinci  Configurator  Pro.  There  the  Rte  generation  and  the  SWC 
generation are performed. 
 
The following code is generated: 
 
In SWC_Sender.c: 
Std_ReturnType Rte_Write_My_TemperatureInterface_My_TemperatureElement(sint16 data) 
 
In SWC_Receiver.c: 
Std_ReturnType Rte_Read_My_TemperatureInterface_My_TemperatureElement(sint16 *data) 
 
 
In Rte_SWC_Sender.h and Rte_SWC_Receiver.h: 
#  define Rte_InitValue_My_TemperatureInterface_My_TemperatureElement (40
 
 
In Rte_SWC_Sender_Type.h and Rte_SWC_Receiver_Type.h: 
#  define My_TemperatureType_LowerLimit (-100) 
#  define My_TemperatureType_UpperLimit (300) 
 
 
 
The data element of the read and write function is typed by sint16. 
The init value is 40 (internal value of configured physical value 20). 
The generated lower limit is -100 and upper limit 300. 
 
 
 
 
Note 
In  the  Rte  generator  version  (4.01.01)  the  generated  negative  included  limits  are 
  shifted by +1. If both limits are negative, the lower and upper limits are inverted. 
These two issues are known and will be fixed in a future version. 
 
 
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
35 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4.2 
Complex data element   
 
This  example  shows  the  design  of  a  complex  application  data  type  referenced  by  a 
sender/receiver port interface data element. 
 
A  sender/receiver  port  interface  is  designed  to  send  a  record  containing  a  temperature 
value in Celsius as first element and a speed value in km/h as second element. 
 
The temperature value is modeled as in chapter 4.1. 
 
The  speed  physical  values  can  be  in  the  range  [0  km/h;  300  km/h]  with  0,5  km/h 
resolution. In other words, the values can be 0 km/h, 0,5 km/h,…, 299,5 km/h, 300 km/h. 
In  the  same  way  as  the  temperature,  speed  needs  an  implementation  type  covering  the 
possible  values  at  code  level.  Uint16  is  chosen.  A  linear  conversion  from  physical  to 
internal  with factor  2 and offset  0  (f(x)=2.x+0)  is  used. The  corresponding  internal  range 
will be [0; 600]. 
 
  A Value application data type (“My_SpeedType”) is created and mapped to uint16 (see 
Figure 4-17). For details about primitive data type creation refer to chapter 4.1. 
 
 
Figure 4-17  My_SpeedType settings 
  A  Record  application  data  type  (“My_RecordType”)  is  created  with  a  temperature 
element as first element and a speed element as second element: 
2014, Vector Informatik GmbH 
Version: 1.1 
36 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
  Right click on “Application Data Type” library is done and “New Record…” is selected 
(see Figure 4-18). 
 
Figure 4-18  New Record application data type 
  Enter the name of the record application data type and create 2 record elements (see 
Figure 4-19). 
 
2014, Vector Informatik GmbH 
Version: 1.1 
37 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-19  Record type creation with 2 record elements 
2014, Vector Informatik GmbH 
Version: 1.1 
38 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
  The corresponding implementation data type is created: 
The corresponding implementation data type shall have a structure corresponding to the 
application  data  type  so  that  each  sub  element  of  the  application  level  has  a 
corresponding element at implementation level. In this example a record implementation 
data type with 2 sub elements is used. 
  Right  click  on  “Implementation  Data  Type”  library  is  done  and  “New  Record…”  is 
selected (see Figure 4-20). 
  The record data type is configured (see Figure 4-21): 
     The name is set: “My_RecordImplementationType” 
  In  the  “Record  Elements”  tab,  a  record  element  matching  with  temperature  at 
implementation level is created: 
The name “TemperatureImplementationRecordElement” is set. 
The  element  type  is  set  to  “Type  Reference”  in  order  not  to  create  a  new 
implementation data type, but to use an existing one. 
The  property  button  is  clicked  to  open  the  dialog  where  this  reference  is  set. The 
type  sint16  is  chosen  corresponding  to  the  implementation  data  type  mapped  to 
“My_TemperatureType”. 
  In a similar way a record matching with speed at implementation level is created: 
The name “SpeedImplementationRecordElement” is set. 
The  element  type  is  set  to  “Type  Reference”  in  order  not  to  create  a  new 
implementation data type, but to use an existing one. 
The  property  button  is  clicked  to  open  the  dialog  where  this  reference  is  set. The 
type  uint16  is  chosen  corresponding  to  the  implementation  data  type  mapped  to 
“My_SpeedType”.  
 
 
Figure 4-20  New Record implementation data type 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
39 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 4-21  Set a record implementation data type 
  The record application data type is now mapped with the record implementation data 
type (see Figure 4-22). 
2014, Vector Informatik GmbH 
Version: 1.1 
40 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 4-22  Record type mapping 
 
 
 
Note 
When the 2 record types are mapped, the “only show compatible Implementation Data 
  Types” is very useful for 2 reasons: 

It provides a reduced list of available types, which makes the selection easier 

It already gives the information if the 2 records types are compatible or not. In 
case the desired implementation data type does not appear in the selection list, 
then the designer has already the information that the types do not match and 
that the configuration is not correct. 
 
 
  A  sender/receiver  port  interface  is  created,  where  the  data  element  is  named 
„RecordElement” and typed by „My_RecordType“ (see Figure 4-23)
 
2014, Vector Informatik GmbH 
Version: 1.1 
41 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-23  Sender/receiver port interface with record element 
  A P-Port prototype referencing „My_RecordInterface” is created in SWC_Sender and 
accessed  by  „SWC_SenderRunnable”. A  similar  R-Port  is  created  at  SWC_Receiver 
and accessed by “SWC_ReceiverRunnable”. 
 
For both ports an init value shall be set in the com spec. Two ways can be followed to 
set the init values: 
>  Manually at the port (see Figure 4-24 and Figure 4-25). 
>  With  a  constant:  a  constant  is  created  (see  Figure  4-26)  and  this  constant  is 
referenced as init value (see Figure 4-27)
 
2014, Vector Informatik GmbH 
Version: 1.1 
42 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-24  Record manual init – part 1 
2014, Vector Informatik GmbH 
Version: 1.1 
43 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-25  Record manual init – part 2 
2014, Vector Informatik GmbH 
Version: 1.1 
44 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-26  Record constant creation 
2014, Vector Informatik GmbH 
Version: 1.1 
45 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-27  Referencing a record constant as init value  
The 2 ports are then connected (see Figure 4-28). 
 
 
Figure 4-28  My_RecordInterface port connection 
 
2014, Vector Informatik GmbH 
Version: 1.1 
46 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
  “My_TypeMappingSet”  has  to  be  referenced  by  SWC_Sender  and  SWC_Receiver, 
which was already done in chapter 4.1. 
  The system description resulting from the configuration done in DaVinci Developer is 
imported  in  DaVinci  Configurator  Pro.  There  the  Rte  generation  and  the  SWC 
generation are performed. 
 
The following code is generated: 
 
In SWC_Sender.c: 
Std_ReturnType Rte_Write_My_RecordInterface_RecordElement(const My_RecordImplementationType *data) 
 
In SWC_Receiver.c: 
Std_ReturnType Rte_Read_My_RecordInterface_RecordElement(My_RecordImplementationType *data) 
 
 
In Rte_Type.h: 
# define Rte_TypeDef_My_RecordImplementationType 
typedef struct 

  sint16 TemperatureImplementationRecordElement; 
  uint16 SpeedImplementationRecordElement
My_RecordImplementationType
 
 
In Rte.c: 
CONST(My_RecordImplementationType, RTE_CONST) Rte_C_My_RecordImplementationType_0 = { 
  40, 0U 
}; 
 
CONST(My_RecordImplementationType, RTE_CONST) Rte_My_RecordConstant = { 
  40, 0U 
}; 
 
 
 
The record data element is typed by My_RecordImplementationType. 
The  record  type  has  2  elements,  TemperatureImplementationRecordElement  of  type 
sint16 and SpeedImplementationRecordElement of type uint16. 
Two constants  are generated for the init  values:  Rte_My_RecordConstant  corresponding 
to the constant created in DaVinci Developer and Rte_C_MyRecordImplementationType_0 
corresponding to the init value set manually. 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
47 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4.3 
Enumeration 
 
Two  enumeration  examples  are  described  in  this  chapter.  The  first  one  (see  4.3.1) 
corresponds  to  enumeration  created  at  application  level.  The  second  one  (see  0) 
corresponds to enumeration created at implementation level. 
 
4.3.1 
Application level 
 
In  this  example  an  enumeration  application data  type  is  created.  It  defines  3  text  values 
and is mapped to uint8. 
 
  A  new  Value  application  data  type  is  created:  “My_EnumerationType”  (see  Figure 
4-29): 
  It  references  “My_EnumerationType_CompuMethod”  which  defines  a  text  table 
conversion (see Figure 4-30)
  This text table contains 3 values (see Figure 4-31): 
 
- Text_00 corresponding to numerical value 0 (range [0;0]) 
 
- Text_01 corresponding to numerical value 1 (range [1;1]) 
 
- Text_02 corresponding to numerical value 2 (range [2;2]) 
 
 
  “My_EnumerationType” 
references 
“My_EnumerationType_Constraint” 
which 
specifies [0;2] as physical range (see Figure 4-32)
  „My_EnumerationType is then mapped to uint8 in „My_TypeMappingSet” (see Figure 
4-33). 
 
Figure 4-29  My_Enumeration type 
2014, Vector Informatik GmbH 
Version: 1.1 
48 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 4-30  My_EnumerationType_CompuMethod 
   
 
Figure 4-31  Enumeration text table setting 
2014, Vector Informatik GmbH 
Version: 1.1 
49 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-32  Enumeration constraint 
 
Figure 4-33  My_Enumeration mapping to uint8 
  A sender/receiver port interface “My_EnumerationInterface” is created. It contains one 
data element of type “My_EnumerationType” “(see Figure 4-34).  
 
Figure 4-34  “My_EnumerationInterface” 
2014, Vector Informatik GmbH 
Version: 1.1 
50 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
  A P-Port is created on the SWC_Sender with write access to the data element in the 
SWC_SenderRunnable, a R-Port is created on the SWC_Receiver with read access to 
the  data  element  in  the  SWC_ReceiverRunnable,  init  values  are  specified  and  both 
ports are connected. 
  “My_TypeMappingSet”  has  to  be  referenced  by  SWC_Sender  and  SWC_Receiver, 
which was already done in chapter 4.1. 
  The system description resulting from the configuration done in DaVinci Developer is 
imported  in  DaVinci  Configurator  Pro.  There  the  Rte  generation  and  the  SWC 
generation are performed. 
 
The following code is generated: 
 
In SWC_Sender.c: 
Std_ReturnType Rte_Write_My_EnumerationInterface_My_EnumerationElement(uint8 data) 
 
In SWC_Receiver.c: 
Std_ReturnType Rte_Read_My_EnumerationInterface_My_EnumerationElement(uint8 *data) 
 
In Rte_SWC_Sender_Type.h and Rte_SWC_Receiver_Type.h: 
#  define My_EnumerationType_LowerLimit (0U) 
#  define My_EnumerationType_UpperLimit (2U) 
 
#  ifndef Text_00 
#   define Text_00 (0U) 
#  endif 
 
#  ifndef Text_01 
#   define Text_01 (1U) 
#  endif 
 
#  ifndef Text_02 
#   define Text_02 (2U) 
#  endif 
 
The data element is typed by uint8. 
The lower limit is 0 and upper limit is 2. 
Each enumeration text is defined with the corresponding uint8 value 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
51 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
4.3.2 
Implementation level 
 
In  this  example  an  enumeration  implementation  data  type  is  created.  It  defines  3  text 
values and has uint8 as reference type. 
 
  A  new  Reference  implementation  data  type  is  created:  “My_EnumerationImplType” 
(see Figure 4-35): 
  It  references  “My_EnumerationImplType_CompuMethod”  which  defines  a  text  table 
conversion (see Figure 4-36). 
  This text table contains 3 values, Text_00 for value 0 (range [0;0]), Text_01 for value 
1 (range [1;1]) and Text_02 for value 2 (range [2;2]) (see Figure 4-37). 
 
Figure 4-35  My_EnumerationImplType 
 
Figure 4-36  My_EnumerationImplType_CompuMethod 
2014, Vector Informatik GmbH 
Version: 1.1 
52 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
  
 
Figure 4-37  My_EnumerationImplType_CompuMethod text table 
 
  A sender/receiver port interface “My_EnumerationImplInterface” is created. It contains 
one data element of type “My_EnumerationImplType“ (see Figure 4-38).  
 
Figure 4-38  My_EnumerationImplInterface 
  A P-Port is created on the SWC_Sender with write access to the data element in the 
SWC_SenderRunnable, an R-Port is created on the SWC_Receiver with read access 
to the data element in the SWC_ReceiverRunnable, init values are specified and both 
ports are connected. 
  The system description resulting from the configuration done in DaVinci Developer is 
imported  in  DaVinci  Configurator  Pro.  There  the  Rte  generation  and  the  SWC 
generation are performed. 
2014, Vector Informatik GmbH 
Version: 1.1 
53 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
 
The following code is generated: 
 
In SWC_Sender.c: 
Std_ReturnType 
Rte_Write_My_EnumerationImplInterface_My_EnumerationImplElement(My_EnumerationImplType data) 
 
* Enumeration Types: 
 * ================== 
 * My_EnumerationImplType: Enumeration of integer in interval [0...255] with enumerators 
 *   Text_00 (0U) 
 *   Text_01 (1U) 
 *   Text_02 (2U) 
 
In SWC_Receiver.c: 
Std_ReturnType  Rte_Read_My_EnumerationImplInterface_My_EnumerationImplElement(My_EnumerationImplType 
*data) 
 
* Enumeration Types: 
 * ================== 
 * My_EnumerationImplType: Enumeration of integer in interval [0...255] with enumerators 
 *   Text_00 (0U) 
 *   Text_01 (1U) 
 *   Text_02 (2U) 
 
 
In Rte_SWC_Sender_Type.h and Rte_SWC_Receiver_Type.h: 
#  define My_EnumerationType_LowerLimit (0U) 
#  define My_EnumerationType_UpperLimit (2U) 
 
#  ifndef Text_00 
#   define Text_00 (0U) 
#  endif 
 
#  ifndef Text_01 
#   define Text_01 (1U) 
#  endif 
 
#  ifndef Text_02 
#   define Text_02 (2U) 
#  endif 
 
In Rte_Type.h: 
# define Rte_TypeDef_My_EnumerationImplType 
typedef uint8 My_EnumerationImplType
 
The data element is typed by My_EnumerationImplType which is defined as uint8. 
Each enumeration text is defined with the corresponding uint8 value 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
54 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
4.4 
Mode declaration 
 
A  mode  transmitted  via  mode  switch  port  interfaces  is  a  data  element  that  can  take  its 
values in a corresponding mode declaration group. 
Mode declaration groups can be created in two different ways. The first one is to create a 
mode declaration group manually in DaVinci Developer, which will then be used in a mode 
switch port interface by SWCs and/or by BswM (see 4.4.1). The second one is to create a 
mode  service  port  in  the  BswM  configuration  in  DaVinci  Configurator  Pro,  which  will 
automatically create a corresponding mode declaration group (see 4.4.2).  
 
4.4.1 
Mode declaration group in DaVinci Developer 
 
  It is possible to create mode declaration groups in DaVinci Developer by right-clicking 
“Mode Declaration Group” library and selecting “New Mode Declaration Group…” (see 
Figure 4-39). 
 
Figure 4-39  New mode declaration group 
  The mode declaration group is configured (see Figure 4-40)
  The name is given 
  The  category  is  set:  alphabetic  or  explicit.  Alphabetic  means  that  the  mode 
declaration  internal  values  will  be  attributed  automatically  in  the  alphabetical  order. 
Explicit means that the designer can set these values himself.  
  The mode declarations are entered. 
The internal values of mode declarations and transition may be entered, but are not 
mandatory (see the note below). 
 
 
Note 
The  Rte  generator  supports  currently  only  alphabetic  category.  That  means,  even  if 
  “Explicit” is set and values are attributed by the designer to the mode declarations, the 
mode declaration internal values are automatically generated following the alphabetical 
order. 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
55 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-40  My_ModeDeclarationGroup 
  A  mode  port  interface  called  “My_ModePortInterface”  is  created.  It  transmits 
“My_Mode” of mode declaration group “My_ModeDeclarationGroup” (see Figure 4-41). 
 
 
Figure 4-41  My ModePortInterface 
  In  this  example  SWC_Sender  is  the  mode  master  and  SWC_Receiver  is  the  mode 
user.  
SWC_Sender resp. SWC_Receiver implements a sender resp. sender port prototype 
referencing  “My_ModePortInterface”.  They  are  connected  to  each  other  (see  Figure 
4-42).  
SWC_SenderRunnable  has  “Send  Mode  Switches”  port  access  on  the  mode 
switch  port,  SWC_ReceiverRunnable  has  “Read  Mode”  port  access  on  the  mode 
switch port (see Figure 4-43). 
 
2014, Vector Informatik GmbH 
Version: 1.1 
56 / 80 
based on template version 5.1.0 





Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-42  Mode ports connection 
 
       
 
Figure 4-43  Mode port access 
 
 
Note 
The type for the mode declaration group in the code is automatically the corresponding 
  platform  type:  if  the  number  of  mode  declarations  is  lower  than  256,  then  the  mode 
declaration  group  is  mapped  automatically  to  uint8.  If  this  number  is  bigger  than  256 
and lower than 65536, then it is mapped to uint16, and so on… 
 
 
 
The  system  description  resulting  from  the  configuration  done  in  DaVinci  Developer  is 
imported in DaVinci Configurator Pro. There the Rte generation and the SWC generation 
are performed. 
 
The following code is generated: 
 
In SWC_Sender.c: 
* Mode Interfaces: 
 * ================ 
 * 
 
 
Std_ReturnType 
Rte_Switch_My_ModePortInterface_My_Mode(Rte_ModeType_My_ModeDeclarationGroup 
mode) 
 *   Modes of Rte_ModeType_My_ModeDeclarationGroup: 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_A_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_B_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_C_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_D_Mode 
 *   - RTE_TRANSITION_My_ModeDeclarationGroup 
 
2014, Vector Informatik GmbH 
Version: 1.1 
57 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
 
In SWC_Receiver.c: 
* Mode Interfaces: 
 * ================ 
 * 
 
 
Rte_ModeType_My_ModeDeclarationGroup 
Rte_Mode_My_ModePortInterface_My_Mode(void) 
 *   Modes of Rte_ModeType_My_ModeDeclarationGroup: 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_A_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_B_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_C_Mode 
 *   - RTE_MODE_My_ModeDeclarationGroup_My_D_Mode 
 *   - RTE_TRANSITION_My_ModeDeclarationGroup 
 * 
 
 
In Rte_Type.h: 
 
typedef uint8 Rte_ModeType_My_ModeDeclarationGroup; 
 
# define RTE_MODE_My_ModeDeclarationGroup_My_A_Mode (0U) 
# define RTE_MODE_My_ModeDeclarationGroup_My_B_Mode (1U) 
# define RTE_MODE_My_ModeDeclarationGroup_My_C_Mode (2U) 
# define RTE_MODE_My_ModeDeclarationGroup_My_D_Mode (3U) 
# define RTE_TRANSITION_My_ModeDeclarationGroup (4U) 
 
The mode declaration group is typed by uint8. 
The mode declaration values are attributed in the alphabetical order. 
  
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
58 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
4.4.2 
Mode service port in BswM configuration 
 
In  DaVinci  Configurator  Pro,  the  BswM  BSWMD  offers  the  possibility  to  create  mode 
switch ports referencing pre-defined mode declaration groups. 
For  instance  it  is  possible  to  create  a  BswM  switch  port  referencing  the  ComM  mode 
declaration group (see Figure 4-44). 
 
 
Figure 4-44  BswM configuration 
 
After configuring the BswM in DaVinci Configurator Pro, it is possible to import its service 
component description in DaVinci Developer. As shown Figure 4-45 BswM is imported in 
the “Service Component Types” library, the mode switch interface referencing the ComM 
mode in the “Service Port Interfaces” library.  
 
Figure 4-45  BswM import in DaVinci Developer 
 
The mode declaration group ComMMode is also imported in the “Mode Declaration Group” 
library (see Figure 4-46) and the corresponding mode declarations are visible by opening it 
(see Figure 4-47). 
 
2014, Vector Informatik GmbH 
Version: 1.1 
59 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-46  Mode declaration group import in DaVinci Developer 
 
Figure 4-47  ComM mode declaration group 
This configuration gives then the following generated code: 
 
In SWC_A.c: 
 
Rte_ModeType_ComMMode 
Rte_Mode_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode(void) 
 
//Modes of Rte_ModeType_ComMMode
//   - RTE_MODE_ComMMode_COMM_FULL_COMMUNICATION 
//   - RTE_MODE_ComMMode_COMM_NO_COMMUNICATION 
//   - RTE_MODE_ComMMode_COMM_SILENT_COMMUNICATION 
//   - RTE_TRANSITION_ComMMode 
In Rte_SWC_A.h: 
 
//Buffers for Mode Management 
extern 
VAR(Rte_ModeType_ComMMode, 
RTE_VAR_NOINIT) 
Rte_ModeMachine_BswM_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode

In Rte.c: 
 
/* mode management initialization part 1 */ 
Rte_ModeMachine_BswM_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode 
= RTE_MODE_ComMMode_COMM_NO_COMMUNICATION; 
 
2014, Vector Informatik GmbH 
Version: 1.1 
60 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
In Rte_Type.h: 
 
//define Rte_TypeDef_ComM_ModeType 
typedef uint8 ComM_ModeType
 
//Definitions for Mode Management 
typedef uint8 Rte_ModeType_ComMMode
 
# define RTE_MODE_ComMMode_COMM_FULL_COMMUNICATION (0U) 
# define RTE_MODE_ComMMode_COMM_NO_COMMUNICATION (1U) 
# define RTE_MODE_ComMMode_COMM_SILENT_COMMUNICATION (2U) 
# define RTE_TRANSITION_ComMMode (3U) 
 
The mode declaration group Com_ModeType is typed by uint8. 
The  mode  declarations  are  available  as  defines  and  their  uint8  value  is  given  in  the 
alphabetical order.  
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
61 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4.4.3 
Mode request port and mapping 
 
 
A  component  requesting  a  mode  change  to  the  mode  master  shall  implement  a 
sender/receiver  P-Port  as  mode  request  port.  The  corresponding  port  interface’s  data 
element  shall  be  typed  by  an  implementation  data  type  referencing  a  compu  method 
containing  an  enumeration  of  the  corresponding  modes.  That  implementation  data  type 
shall be mapped to the corresponding mode declaration group. 
 
  The  mode  declaration  group  for  the  example  will  be  My_ModeDeclarationGroup 
presented Figure 4-48. 
 
Figure 4-48  My_ModeDeclarationGroup 
  A corresponding implementation data type is created: 
My_ModeDeclarationGroup_IType. 
  It is defined as type reference to uint8 
  It contains a compu method which defined an enumeration of the 4 modes from 
My_ModeDeclatationGroup. The same strings shall be used. See Figure 4-49. 
 
2014, Vector Informatik GmbH 
Version: 1.1 
62 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
  
 
Figure 4-49  My_ModeDeclarationGroup_IType 
  The  mode  declaration  group  and  the  implementation  data  type  are  mapped  in  a 
ModeRequestTypeMap (Figure 4-50). 
 
 
Figure 4-50  Mode declaration group mapping 
  The corresponding SWC shall implement a port and reference the type mapping set. 
  A service sender/receiver port interface is created containing 1 data element typed 
by My_ModeDeclarationGroup_IType (Figure 4-51)
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
63 / 80 
based on template version 5.1.0 





Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 4-51  My_ModeRequestInterface 
  A service P-Port prototype referencing this port interface is created on the SWC 
(Figure 4-52)
 
Figure 4-52  My_ModeRequestPort 
  The type mapping set is referenced by the SWC (Figure 4-53). 
 
Figure 4-53  Type mapping set reference for mode request 
 
2014, Vector Informatik GmbH 
Version: 1.1 
64 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
  A runnable of the SWC shall have write access on the created port. 
  In DaVinci Configurator, the corresponding mode request port on BswM can be 
created and mapped to the SWC port. 
 
  The generated code provides the following for the SWC: 
 
Type and enumeration definition: 
 
* Enumeration Types: 
 * ================== 
 *  My_ModeDeclarationGroup_IType:  Enumeration  of  integer  in  interval  [0...255]  with 
enumerators 
 *   My_A_Mode (0U) 
 *   My_B_Mode (1U) 
 *   My_C_Mode (2U) 
 *   My_D_Mode (3U) 
 
 
Mode request API for the SWC: 
 
Std_ReturnType Rte_Write_My_ModeRequestPort_My_ModeRequest(My_ModeDeclarationGroup_IType 
data) 
 
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
65 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4.5 
Implementation data type examples 
 
As  a  summary,  the  two  following  examples  are  showing  how  implementation  data  types 
can be created as type reference (see 4.5.1) or as value (see 0)
   
4.5.1 
Type reference 
 
It is possible to create an implementation data type out of an existing implementation data 
type. This is done by right-clicking the “Implementation Data Types” library and selecting 
“New Type Reference…”. 
 
As shown Figure 4-54, a name is given, as well as a reference to another implementation 
data type in the “Data Type” field. For the example uint8 is chosen. 
  
 
Figure 4-54  New type reference 
At Rte generation, the following is generated in Rte_Type.h: 
# define Rte_TypeDef_MyImpl_Type_Ref 
typedef uint8 MyImpl_Type_Ref
 
The  new  created  implementation  data  type  is  used  and  typed  via  typedef  by  the 
referenced data type. 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
66 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
4.5.2 
Value 
 
  It  is  possible  to  create  an  implementation  data  type  of  category  value  referencing  a 
base  type.  This  is  done  in  this  example  by  right-clicking  the  “Implementation  Data 
Types” library and selecting “New Value…”. 
  The Value implementation data type gets a name: “My_ImplValue” in this example. 
  A reference to a base type has to be given in the “Base Type” field (see Figure 4-55)
In this example a “My_ImplValue_base” base type is used (see Figure 4-56). A valid 
“Native Declaration” must be set in the base type: unsigned char here. 
  It is also optionally possible to set a constraint to the implementation data type, which 
is done in My_ImplValue_Constraint (see Figure 4-57). It is set here that the internal 
values are limited to the range [0;150]. 
 
 
Figure 4-55  Value implementation data type 
 
2014, Vector Informatik GmbH 
Version: 1.1 
67 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
Figure 4-56  My_ImplValue_base base type 
 
Figure 4-57  Implementation type constraint 
  The  configured  implementation  data  type  is  generated  via  Rte  generator  and  the 
following can be seen: 
 
In Rte_Type.h: 
# define Rte_TypeDef_My_ImplValue 
typedef unsigned char My_ImplValue; 
 
//Primitive Types: 
// ================ 
//My_ImplValue: Integer in interval [0...150] 
 
The new created implementation data type is typed via typedef by the native declaration of 
the  referenced  base  type. As  explained  chapter  3.5,  this  example  introduces  a  platform 
dependency because “unsigned char” meaning is platform dependent. 
The constraint set in the configuration appears only as comments in the code. 
2014, Vector Informatik GmbH 
Version: 1.1 
68 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
5  Additional information 
5.1 
Compatibility and conversion 
 
  It is possible to create several implementation data types with the same name if they 
belong to 2 different packages.  
At  code  generation  only  1  implementation  data  type  is  generated.  In  case  the 
implementation data types with the same name are not exactly the same (differences 
in  compu  methods,  constraints…)  an  information  message  #40286  is  displayed  in 
DaVinci Developer and in DaVinci Configurator Pro (see Figure 5-1)
 
Figure 5-1  Info Message #40286 
 
  Compatibility  of  ports  is  verified  in  DaVinci  Developer  based  on  the  name  and  the 
category of the connected data elements. This check contains: 
  Data  elements  exchanged  by  both  ports  shall  have  the  same  category  (Value, 
Record, Array…) 
  Primitive data elements exchanged by both ports shall have the same name 
  In case of Record: 
  For each receiver sub element, there shall be a sender sub element with the same 
name:  
E.g.: 
>  Sender of {element1; element2; element3} and receiver of {element1; element3} 
are compatible. 
>  Sender  of  {element1;  element2}  and  receiver  of  {element1;  element3}  are  not 
compatible. 
>  Sender of {element1} and receiver of {element1; element2} are not compatible. 
2014, Vector Informatik GmbH 
Version: 1.1 
69 / 80 
based on template version 5.1.0 




Technical Reference Autosar 4.0 - DataTypes 
  In case of Array, array data elements exchanged by both ports shall have the same 
name 
 
  No conversion between data types is realized by the Rte in the generated code. 
 
 
Note 
Compatibility  checks  are  about  to  be  extended  in  DaVinci  Developer  and  DaVinci 
  Configurator Pro in the future releases. 
 
 
 
 
5.2 
Measurement and calibration 
 
For  specific  ECU  project  purposes  data  elements  may  have  to  be  accessed  via 
measurement and calibration tools (MCD tools). 
In  order  to  generate  an  A2L  file  used  by  an  MCD  tool,  the  A2L  generation  has  to  be 
activated in the Rte configuration. This configuration is done in DaVinci Configurator Pro 
as shown Figure 5-2.  
 
Figure 5-2  Rte configuration for A2L generation 
A2L files are generated in /Config/McData/ folder of the ECU project (see Figure 5-3). 
 
 
Figure 5-3  A2L generation folder  
2014, Vector Informatik GmbH 
Version: 1.1 
70 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
The following lines summarize what  is generated  and thus accessible from an MCD tool 
using the generated A2L file. 
  The mode port prototypes are always visible in the A2L file. A text table is joined to it 
representing the conversion between internal value and mode declaration name. 
  Data elements of Sender/Receiver interfaces are: 
  Not  accessible  if  “NotAccessible”  is  set  for  the  data  element  in  the  port  interface 
editor. 
  Read only if “ReadOnly” is set for the data element in the port interface editor. 
  Read/Write if “ReadWrite” is set data element in the port interface editor. 
 
 
 
Note 
Measurement and calibration settings in application and implementation data types are 
  over ridden by the setting at the data element in DaVinci Developer. 
 
 
 
  Unit is accessible  
  Conversion function and text tables are accessible: 
  1:1 is set in case factor is 1 and offset 0 in DaVinci developer 
  Phys to Int factor Fp offset Op makes (Fp ≠ 0): “int to phys f(x)= (1/Fp).x-Op” in A2L 
file 
  Int to Phys factor Fi offset Oi makes “int to phys f(x)= Fi.x + Op” in A2L file 
 
 
 
Note 
Factors and offsets set for units in DaVinci Developer are not taken into account 
  in A2L files. 
 
 
  Operation  arguments  are  not  visible  in  the  A2L  even  if  explicitly  set  in  DaVinci 
Developer. 
 
  Calibration parameters:  
  They  are  accessible  as  set  in  DaVinci  Developer  (NotAccessible,  ReadOnly  or 
ReadWrite). 
  The unit is not available: the calibration parameter is only handled at implementation 
level with internal values. 
 
2014, Vector Informatik GmbH 
Version: 1.1 
71 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
5.3 
Symbols 
 
In  DaVinci  Developer  certain  elements  may  have  a  “Symbol”  field.  This  is  the  case  of 
implementation data types. A symbol field may be used in case the name of the element in 
the code shall be different from the name specified in DaVinci Developer. 
For instance, the implementation data type created in chapter 4.5.1 can receive a Symbol 
name  and  value  as  done  Figure  5-4.  In  this  example,  the  name  of  the  symbol  is 
“MyImpl_Type_Ref_Symbol” and the value is “MyImpl_Type_Ref_Value”. 
 
 
Figure 5-4  Symbol field for implementation data type 
The corresponding code generated is: 
 
In Rte_Type.h: 
# define Rte_TypeDef_MyImpl_Type_Ref_Value 
typedef uint8 MyImpl_Type_Ref_Value
 
The Value of the Symbol field is used as implementation data type name in the generated 
code. 
 
 
 
Note 
Symbols have a name field and a value field. 
  The  name  field  is  the  name  of  the  symbol  element  handled  by  the  tools  and  the 
generators. The name that really appears in the code is what the value field contains. 
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
72 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
5.4 
Data type mapping assistant 
 
A data type mapping assistant is available in DaVinci Developer. It is accessible by right 
click on the ECU Project root and by selecting “Data Type Mapping…” in the context menu 
(see Figure 5-5). 
 
 
Figure 5-5  Data type mapping assistant opening 
 
Figure 5-6  Data type mapping assistant 
 
2014, Vector Informatik GmbH 
Version: 1.1 
73 / 80 
based on template version 5.1.0 


Technical Reference Autosar 4.0 - DataTypes 
This  assistant  is  a  comfort  editor  allowing  the  mapping  of  application  data  types  to 
implementation data types. In this editor it is possible: 
  To let the assistant finding and mapping automatically compatible implementation data 
types using the “Find Mapping” button 
  To let the assistant creating automatically a compatible implementation data types and 
mapping it using the “Find Mapping” button 
  To  create  manually  the  mapping  by  right-clicking  on  the  application  data  type  line, 
choose “Map…” and select the implementation data type among the existing ones. 
 
 
 
Note 
The  assistant  is  working  only  in  the  context  of  the  ECU  project.  That  means  only 
  application  data  types  that  are  used  in  an  ECU  project  will  be  displayed.  If  an 
application data type is only created in the library but not used, it will not appear in the 
list. 
 
 
 
  Description of the editor fields: 
 
>  “Implementation  Data  Types”:  package  where  the  automatically  created 
implementation data types shall be saved. 
 
>  “Platform Types”: package where the assistant shall look for platform types. 
 
 
>  “Prefix”: prefix to add to the automatically created implementation data types. 
 
>  “Postfix”: suffix to add to the automatically created implementation data types. 
 
 
>  “Use Platform Types”: if checked, the assistant will search only in the platform types’ 
list to find a compatible implementation data type to map. 
 
>  “Use  custom  Implementation  Data  Types”:  lets  the  assistant  searching  for  custom 
implementation data types. 
 
>  “Create  primitive  Data  Types”:  lets  the  assistant  creating  new  primitive 
implementation data types 
2014, Vector Informatik GmbH 
Version: 1.1 
74 / 80 
based on template version 5.1.0 



Technical Reference Autosar 4.0 - DataTypes 
 
>  “Create  complex  Data  Types”:  lets  the  assistant  creating  new  complex 
implementation data type 
 
>  “Prefer  integer  to  float  Data  Type”:  lets  the  assistant  mapping  by  preference  to 
integer types than to float types. 
 
>  “Allow  selection  of  incompatible  Data  Types”:  allows  that  non  Autosar  compatible 
data types are mapped 
 
>  “Find Mapping”: starts to search for a compatible implementation data type 
 
 
>  “Reset”: resets to the state when the editor was open  
 
 
  2 examples are presented here: 
 
>  1st Example:  
 
After  pressing  „Find  Mapping“,  the  mapping  assistant  proposes  to  map  with  uint8  (see 
Figure  5-7).  The  state  is  set  as  “new”  because  it  is  a  new  proposal  from  the  assistant. 
Pressing “ok” or “apply now” creates the mapping and changes the state to “exists”. The 
new  mapping  creation  is  reflected  by  Figure  5-9:  a  new  data  type  mapping  set  with  the 
default  name  “DataTypeMappings_DEV”  is  created  where  the  application  data  type  is 
mapped to uint8 and the corresponding SWC is referencing that data type mapping set. 
 
 
Figure 5-7  New mapping 
 
 
Figure 5-8  Existing mapping 
2014, Vector Informatik GmbH 
Version: 1.1 
75 / 80 
based on template version 5.1.0 





Technical Reference Autosar 4.0 - DataTypes 
     
 
 
 
Figure 5-9  Created after new mapping 
 
>  2nd example: 
 
„Create primitive Data Types“ is checked. By clicking “Find Mapping” the state changes to 
“create data type” (see Figure 5-10).  
Clicking “ok” or “apply now” a new implementation data type is created and mapped to the 
application data type. Its name starts with the “Prefix” field, then the application data type 
name and then the “Postfix” field. The state changes to “exists” (see Figure 5-11). 
The new implementation data type can be found in  the  implementation data type library, 
the  mapping  in  DataTypeMappings_DEV,  which  is  referenced  by  the  SWC  (see  Figure 
5-12)

 
 
Figure 5-10  New mapping with implementation data type creation 
2014, Vector Informatik GmbH 
Version: 1.1 
76 / 80 
based on template version 5.1.0 







Technical Reference Autosar 4.0 - DataTypes 
 
 
Figure 5-11  Existing mapping with implementation data type creation 
 
 
 
 
Figure 5-12  Created after new mapping with implementation data type creation 
 
 
 
 
Note 
The  assistant  needs  information  from  the  application  data  type  constraints  and/or 
  compu methods to be able to map it. In case this information is not sufficient, then the 
assistant  will  not  be  able  to  map  automatically  and  the  state  will  be  “no  mapping 
possible”: 
  
 
 
 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
77 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
5.5 
Type emitter 
 
As  defined  by  Autosar  implementation  data  types  have  a  “Type  emitter”  parameter.  It 
defines the entity that shall provide the code definition of the implementation data type. 
 
If  Type  emitter  is  set  to  “RTE”  or  is  empty,  the  RTE  shall  generate  a  typedef  for  the 
implementation data type according to the native declaration of the  referenced base type 
(category Value) or according to the referenced implementation data type (category Type 
Reference). 
If Type  emitter  has  any  other  value,  then  the  RTE  does  not  generate  the  corresponding 
typedef.  It  is  here  intended  that  the  definition  of  that  implementation  data  type  will  be 
provided by another entity. 
 
2014, Vector Informatik GmbH 
Version: 1.1 
78 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
6  Glossary and Abbreviations 
6.1 
Glossary 
Term 
Description 
 
 
 
 
6.2 
Abbreviations 
Abbreviation 
Description 
SWC 
Software Component 
BswM 
Basic Software Manager 
ComM 
Communication Manager 

Programming language C 
 
 
2014, Vector Informatik GmbH 
Version: 1.1 
79 / 80 
based on template version 5.1.0 

Technical Reference Autosar 4.0 - DataTypes 
7  Contact 
Visit our website for more information on 
 
>  News 
>  Products 
>  Demo software 
>  Support 
>  Training data 
>  Addresses 
 
www.vector.com 
 
2014, Vector Informatik GmbH 
Version: 1.1 
80 / 80 
based on template version 5.1.0 

Document Outline


21 - TechnicalReference_EcuConfigurationFiles

Microsoft Word - TechnicalReference_EcuConfigurationFiles.doc

23 - TechnicalReference_EcuConfigurationFiless


 
 
 
 
 
 
 
 
 
 
 
 
ECU-C File Handling 
Technical Reference 
 
 
 
 
Version 1.13 
 
 
 
 
 
 
Authors: 
Michael Schuele, Matthias Wernicke 
Version: 
1.13 
Status: 
released (in preparation/completed/inspected/released) 
 
 
 


ECU-C File Handling Technical Reference 
 
History 
 
Author 
Date 
Version 
Remarks 
M. Schuele 
2009-02-19 
0.1.0 
Initial version 
M. Schuele 
2009-04-11 
1.0.0 
final version 
M. Wernicke  2009-04-17 
1.1 
Review and update 
M. Schuele 
2009-08-03 
1.2 
Added description of difference dialog 
M. Schuele 
2010-01-27 
1.3 
Added new ECU-C parameters for DaVinci 3.0 
M. Wernicke  2010-01-28 
1.4 
Review and update 
M. Schuele 
2010-05-05 
1.5 
Introduced different but equivalent parameter values 
M. Schuele 
2010-05-14 
1.6 
Added new ECU-C parameters for DaVinci 3.0 SP2 
M. Schuele 
2010-07-20 
1.7 
Added new ECU-C parameters for DaVinci 3.0 SP3 
M. Schuele 
2010-11-29 
1.8 
Added new ECU-C parameters for DaVinci 3.0 SP4 
M. Schuele 
2011-05-06 
1.9 
ComTimeoutFactor synchronization is configurable 
M. Schuele 
2012-02-02 
1.10 
Added new ECU-C parameters for DaVinci 3.0 SP5 and 3.1 
M. Schuele 
2012-08-30 
1.11 
Added a note about AUTOSAR 4 
M. Schuele 
2013-05-03 
1.12 
Added new ECU-C parameters for DaVinci 3.5 
M. Schuele 
2014-03-27 
1.13 
Added SchM config to Rte section 
 
2014, Vector Informatik GmbH 
Version: 1.13 
2 / 34 
 
 


ECU-C File Handling Technical Reference 
 
Contents 
1  Overview ......................................................................................................................... 5 
1.1 
Intended Audience .......................................................................................... 5 
1.2 
Terms and Acronyms ....................................................................................... 5 
2  The ECU-Configuration Process ................................................................................... 7 
2.1 
The ECU-Configuration File ............................................................................ 8 
3  DaVinci DEV and the ECU-C file .................................................................................. 11 
3.1 
Project Assistant............................................................................................. 11 
3.2 
Initial synchronization (bi-directional update) .................................................. 11 
3.3 
Automatic synchronization ............................................................................ 12 
3.4 
ECU-C file locking ......................................................................................... 12 
3.5 
BSWMD files ................................................................................................. 13 
3.5.1 
Pre- and Recommended config sections ....................................................... 13 
3.6 
Synchronizing an ECU-C file ......................................................................... 13 
3.6.1 
Step 1: Analysis of the RTE configuration in the workspace .......................... 14 
3.6.2 
Step 2: Comparison of workspace and ECU-C file ........................................ 15 
3.6.3 
Synchronization direction “import” ................................................................. 16 
3.6.4 
Synchronization direction “export” ................................................................. 16 
3.6.5 
ECU-Configuration difference dialog ............................................................. 16 
4  ECU-Configuration parameters ................................................................................... 18 
4.1 
Vendor Specific Configuration Parameters .................................................... 18 
4.2 
Rte module ................................................................................................... 18 
4.2.1 
Parameters ................................................................................................... 18 
4.3 
SchM module ................................................................................................ 19 
4.3.1 
General ......................................................................................................... 19 
4.3.2 
Parameters ................................................................................................... 20 
4.3.3 
Rte ................................................................................................................ 20 
4.3.4 
Os 20 
4.4 
Com module.................................................................................................. 21 
4.4.1 
Parameters ................................................................................................... 21 
4.4.2 
Equivalent parameter values ......................................................................... 22 
4.4.2.1 
ComTimeoutFactor ....................................................................................... 23 
4.5 
Os module .................................................................................................... 23 
4.5.1 
Parameters ................................................................................................... 23 
4.5.2 
Equivalent parameter values ......................................................................... 26 
4.6 
NvM module .................................................................................................. 26 
4.6.1 
Parameters ................................................................................................... 26 
2014, Vector Informatik GmbH 
Version: 1.13 
3 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.6.2 
Equivalent parameter values ......................................................................... 27 
4.7 
Board ............................................................................................................ 27 
4.7.1 
Parameters ................................................................................................... 27 
4.7.2 
Equivalent parameter values ......................................................................... 28 
4.8 
ComSignals and ComSignalGroups .............................................................. 28 
4.8.1 
dbc files ......................................................................................................... 28 
4.8.2 
ECU-Extract .................................................................................................. 28 
4.8.3 
AUTOSAR 2.1 ............................................................................................... 29 
4.8.4 
AUTOSAR 3.x ............................................................................................... 29 
4.8.5 
Relevant ComSignals .................................................................................... 29 
4.8.6 
Callbacks ...................................................................................................... 29 
5  Best practices .............................................................................................................. 31 
5.1 
Always work on the latest communication databases .................................... 31 
5.2 
Do not edit the same module configuration in different tools at the same 
time ............................................................................................................... 31 
5.3 
Ensure that all tools use the same max. SHORT-NAME length ..................... 32 
5.4 
ECU-C files have to be valid according to the AUTOSAR schema ................ 32 
5.5 
Configuration elements must have unique SHORT-NAMEs .......................... 33 
6  Contact ......................................................................................................................... 34 
2014, Vector Informatik GmbH 
Version: 1.13 
4 / 34 
 
 



ECU-C File Handling Technical Reference 
 
1   Overview 
DaVinci  Developer  is  part  of  Vector’s  solution  for  AUTOSAR  compatible  ECU 
development. It is used to configure and generate the Rte in AUTOSAR 3.x based projects 
and therefore interacts with other BSW configurators through the ECU-Configuration file. 
This  document  describes  the  configuration  process  related  to  DaVinci  Developer  from  a 
technical  point  of  view,  trying  to  give  the  user  a  better  understanding  of  the  internal 
processes and how the tool reacts in different situations. 
 
 
 
Note 
  Starting  with  DaVinci  Developer  3.3,  AUTOSAR  4.0  based  software  designs  can  be 
created  and  edited.  However,  the  configuration  and  generation  of  the AUTOSAR  4.0 
Rte  has  been  moved  from  DaVinci  Developer  to  DaVinci  Configurator  Pro. Therefore 
this document is only relevant for AUTOSAR 3.x based projects. 
 
 
1.1 
 Intended Audience 
This  document  aims  at  ECU  developers  who  are  involved  in  the  AUTOSAR  compatible 
ECU-Configuration process and use DaVinci Developer to configure and generate the Rte 
module. 
As DaVinci DEV updates the ECU-Configuration file automatically during save and load of 
a  workspace,  the  presented  information  is  not  essential  when  working  with  the  tools  but 
provides  some  additional  information  how  the  ECU-Configuration  process  is  handled 
behind the scenes. 
1.2 
Terms and Acronyms 
Term 
Definition 
DaVinci DEV 
DaVinci Developer 
NWD 
Network Designer 
AR 
AUTOSAR – Automotive Open System Architecture 
GUI 
Graphical user interface 
Rte 
Runtime environment 
BSW 
Basic Software 
BSWMD 
Basic Software Module Description 
2014, Vector Informatik GmbH 
Version: 1.13 
5 / 34 
 
 


ECU-C File Handling Technical Reference 
 
ECU-C file 
ECU-Configuration file 
ECU-C-Synchronization  Synchronization  of  DaVinci  DEV  workspace  with  the 
data in an ECU-C file 
 
2014, Vector Informatik GmbH 
Version: 1.13 
6 / 34 
 
 


ECU-C File Handling Technical Reference 
 
2  The ECU-Configuration Process 
 
Vector
SW-Components
DaVinci DEV
RTE
Communication
ECU Extract of 
System Description

Vector
BSW
DaVinci
Configurator Pro
Basic Software
Module Description

ECU Cfg
Descr

 
Figure 2-1 Basic SW Configuration process 
Figure  2-1  displays  the  ECU  configuration  process  as  it  is  supported  by  Vector’s 
AUTOSAR  solution.  All  configuration  tools  read  from  and  write  to  a  common  ECU-
Configuration  file  which  will  be  used  by  the  different  BSW  code  generators  after  the 
configuration of all modules has been completed. 
The various BSW modules are part of different layers of the AUTOSAR stack with the Rte 
lying on top. Whenever one module utilizes another one its configuration likely depends on 
the configuration of the utilized module and the configurator has to read or even write not 
only the configuration section corresponding to his own module but also the section of the 
other module. 
Since this document is focused on DaVinci DEV, chapter 4 describes the dependencies of 
the  Rte  configuration  on  other  module  configurations  in  detail.  But  before  going  into 
details, the next section provides some basic knowledge about the ECU-Configuration file 
structure. 
2014, Vector Informatik GmbH 
Version: 1.13 
7 / 34 
 
 


ECU-C File Handling Technical Reference 
 
2.1 
The ECU-Configuration File 
AUTOSAR  specifies  all  configuration  parameters  of  a  BSW  module  as  a  so  called 
„Standardized  Module  Definition“.  These  definitions  are  contained  in  an  XML-Document 
(AUTOSAR_EcucParamDef.arxml) and are modeled according to the „ECU Configuration 
Parameter Definition Meta model“.  
To  support  vendor  specific  configuration  parameters,  BSW  modules  may  provide  a 
BSWMD  („Vendor  Specific  Module  Definition“)  file  which  includes  the  standardized 
parameter  definitions  for  the  particular  module  and  defines  additional  parameters. 
Additionally,  a  BSWMD  may  contain  a  section  with  a  pre-configuration,  i.e.  parameter 
values  which  cannot  be  changed,  or  a  section  with  a  recommended  configuration,  i.e. 
parameter values which are appropriate for most use cases but can still be changed. 
BSWMD  files  define  which  parameters  are  available  to  configure  a  BSW  module,  an 
example is given in Figure 2-2. The ECU-Configuration file contains the actual parameter 
values, i.e. the configuration of the modules used on a specific ECU, an example is given 
in Figure 2-1. 
 
<AUTOSAR> 
  <TOP-LEVEL-PACKAGES> 
    <AR-PACKAGE> 
      <SHORT-NAME>MICROSAR</SHORT-NAME> 
      <ELEMENTS> 
        <MODULE-DEF> 
          <SHORT-NAME>Com</SHORT-NAME> 
          <CONTAINERS> 
            <PARAM-CONF-CONTAINER-DEF> 
              <SHORT-NAME>ComConfig</SHORT-NAME> 
              <SUB-CONTAINERS> 
                <PARAM-CONF-CONTAINER-DEF> 
                  <SHORT-NAME>ComSignal</SHORT-NAME> 
                  <PARAMETERS> 
                    <INTEGER-PARAM-DEF> 
                      <SHORT-NAME>ComBitPosition</SHORT-NAME> 
                      <MAX>63</MAX> 
                      <MIN>0</MIN> 
 
Figure 2-2 Configuration parameter definition of “ComBitPosition” in the BSWMD file 
 
2014, Vector Informatik GmbH 
Version: 1.13 
8 / 34 
 
 


ECU-C File Handling Technical Reference 
 
<AUTOSAR> 
<TOP-LEVEL-PACKAGES> 
<AR-PACKAGE> 
<SHORT-NAME>MyProject</SHORT-NAME> 
<ELEMENTS> 
<ECU-CONFIGURATION> 
<SHORT-NAME>MyEcu</SHORT-NAME> 
<ECU-EXTRACT-REF DEST="SYSTEM"> 
/VehicleProject/ReceiverEcu 
</ECU-EXTRACT-REF> 
<MODULE-REFS> 
<MODULE-REF DEST="MODULE-CONFIGURATION"> 
/MyProject/Com 
</MODULE-REF> 
</MODULE-REFS> 
</ECU-CONFIGURATION> 
 
<MODULE-CONFIGURATION> 
<SHORT-NAME>Com</SHORT-NAME> 
<DEFINITION-REF DEST="MODULE-DEF"> 
/AUTOSAR/Com 
</DEFINITION-REF> 
<CONTAINERS> 
<CONTAINER> 
<SHORT-NAME>ComConfig</SHORT-NAME> 
<DEFINITION-REF DEST="PARAM-CONF-CONTAINER-DEF"> 
/AUTOSAR/Com/ComConfig 
</DEFINITION-REF> 
<SUB-CONTAINERS> 
<CONTAINER> 
<SHORT-NAME>Signal_1</SHORT-NAME> 
<DEFINITION-REF DEST="PARAM-CONF-CONTAINER-DEF"> 
/AUTOSAR/Com/ComConfig/ComSignal 
</DEFINITION-REF> 
<PARAMETER-VALUES> 
<INTEGER-VALUE> 
<DEFINITION-REF DEST="INTEGER-PARAM-DEF"> 
/AUTOSAR/Com/ComConfig/ComSignal/ComBitPosition 
</DEFINITION-REF> 
<VALUE>7</VALUE> 
</INTEGER-VALUE> 
[…] 
 
Figure 2-3 Value specification for configuration parameter “ComBitPosition” in the ECU-C file 
The two files are connected by means of standard AUTOSAR references as defined in the 
specification „Model Persistence Rules for XML“. A parameter is configured in the ECU-C 
file  by  referencing  its  parameter  definition  element  included  in  the  BSWMD  file  (via 
<DEFINITION-REF>)  and  defining  the  actual  value  (highlighted  in  red  in  the  given 
examples). 
2014, Vector Informatik GmbH 
Version: 1.13 
9 / 34 
 
 


ECU-C File Handling Technical Reference 
 
As  each  BSW  module’s  parameters  are  defined  in  a  separate  <MODULE-DEF>,  one 
<MODULE-CONFIGURATION>  is  needed  for  each  of  the  BSW  modules.  The  complete 
configuration  of  the  ECU  is  defined  by  <ECU-CONFIGURATION>  which  references  all 
relevant BSW module configurations. 
All  “Standardized  Module  Definitions” are  included  in a package  named  “AUTOSAR” and 
only  those  are  allowed  to  be  placed  there.  “Vendor  Specific  Module  Definitions”  must  be 
included in a different package; Vector modules use “MICROSAR” as the package name. 
Since it is required that custom BSWMD files must include all standardized parameters as 
well,  the  package  name  is  visible  in  all  references  to  the  parameter  definitions.  Hence, 
switching  to  another  BSWMD  requires  adaption  of  all  corresponding  references  in  the 
ECU-C file. 
As  already  mentioned,  a  module’s  configuration  may  depend  on  the  settings  of  another 
module. In this case a reference parameter contains an AUTOSAR reference as its value, 
pointing  into  the  configuration  of the  other module, e.g.  the  runnable mapping  of  the  Rte 
module  configuration  references  the  task  of  the  Os  configuration  it  is  mapped  to  via 
<VALUE-REF DEST="CONTAINER">/MyProject/Os/Task1</VALUE-REF>. 
2014, Vector Informatik GmbH 
Version: 1.13 
10 / 34 
 
 


ECU-C File Handling Technical Reference 
 
3  DaVinci DEV and the ECU-C file 
As displayed in Figure 2-1, DaVinci DEV is used to configure and eventually generate an 
AUTOSAR compatible RTE. Obviously this requires reading from and writing to the Rte 
module configuration in the ECU-C file, but also to other modules, which directly interface 
the RTE (called depending modules within this document). Depending modules are Com, 
NvM and Os. These modules may be read and/or changed, too. Some of these foreign 
parameters are directly visible and changeable; some are automatically derived from other 
settings or the software design. Some parameters are needed to ensure that the 
generated code of different BSW generators matches regarding used and/or provided 
APIs, handles and other interface related code. Details about the affected parameters and 
their sources or relation to the Rte configuration are given in chapter 4. 
3.1 
Project Assistant 
The most convenient way to create a new ECU-C file is the Project Assistant (available via 
the menu item File | Project Assistant). The Project Assistant automatically creates one or 
more1 ECU-C files based on an ECU Extract of System Description and a SIP (Software 
Integration Package) from Vector, and sets up an ECU-Project in DaVinci DEV. 
3.2 
Initial synchronization (bi-directional update) 
To update an existing ECU-C file created by any third party tool without involving DaVinci 
DEV, you have to open the properties dialog of the ECU-Project (see Figure 3-1). The 
“select file” button (labeled “…”) shows a “File Open” dialog where an existing ECU-C file 
can be selected. The selected file is analyzed and if the configuration does not match the 
workspace settings, a synchronization dialog is displayed (this is explained in detail in 
section3.6.1). When the properties dialog is closed the ECU-C file will be assigned to the 
ECU-Project. To perform the synchronization process again, you can then select 
“Synchronize ECU-Configuration” from the context menu of the ECU-Project. 
 
                                            
1 Several ECU-C files are created if „one file per module“ is selected in the „Output Paths“ section. 
2014, Vector Informatik GmbH 
Version: 1.13 
11 / 34 
 
 



ECU-C File Handling Technical Reference 
 
 
Figure 3-1 ECU-C file reference in the ECU-Project properties dialog 
Before the Rte generator is started, DaVinci DEV checks if the ECU-Project has an ECU-C 
file assigned and automatically executes the synchronization process. This ensures that 
the current workspace settings reflect the settings in the ECU-C file and that the ECU-C 
file contains the current configuration of the workspace. Both configurations must match 
because all code generators of the different modules have to work with exactly the same 
ECU configuration data. 
3.3 
Automatic synchronization 
Once  the  ECU-C file  is  assigned  to the ECU-Project  it  is  checked for  consistency  during 
every  load  or  save  of  the  workspace.  This  ensures  that  other  tools  always  work  with  a 
consistent configuration. 
3.4 
ECU-C file locking 
The  tools  DaVinci  Configurator,  DaVinci  Developer  and  GENy  implement  a  locking 
mechanism to ensure that the user edits a specific configuration only in a single tool at a 
time. If the configuration is changed and not yet saved in one tool the other tools consider 
the configuration as read-only and display this state accordingly. This mechanism targets 
on  a  single  user’s  daily  work,  it  does  not  support  distributed  development  or  multi-user 
scenarios. 
2014, Vector Informatik GmbH 
Version: 1.13 
12 / 34 
 
 


ECU-C File Handling Technical Reference 
 
3.5 
BSWMD files 
The ECU-Project properties dialog allows selecting the BSWMD files for each of the 
potentially modified modules. These files are needed for two reasons: 
n  
Since configuration parameters are identified through an absolute reference to their 
parameter definition, the name of the root package in the BSWMD file has to be 
known. 
n  
DaVinci DEV only exports Vector specific configuration parameters if the 
corresponding BSWMD file is assigned to the ECU-Project. 
The selection of a specific BSWMD file for the Rte is not required because DaVinci DEV 
only configures the Vector’s MICROSAR RTE, which is based on the standard AUTOSAR 
BSWMD file of the RTE. 
 
If the ECU-C file follows the AUTOSAR Releases 2.1 Specification, DaVinci DEV uses the 
standard module definitions, <DEFINITION-REF> values therefore begin with 
“/AUTOSAR”. 
 
If the ECU-C file follows the AUTOSAR Releases 3.x Specification, DaVinci DEV implicitly 
uses the Rte BSWMD file, <DEFINITION-REF> values therefore begin with 
“/MICROSAR”. 
 
If there’s a mismatch between the configured BSWMD file and the module configuration in 
the ECU-C file (e.g. the BSWMD file’s package name is MICROSAR and the ECU-C file’s 
module configuration references an AUTOSAR package), the definition of the ECU-C file is 
used. A message about this misconfiguration is written to the “Action Log” window saying: 
 
ActionLog output 
 
Inconsistent BSWMD configuration detected: 
/MICROSAR/Os is defined by BSWMD file D:\BSWMD_files\Os_bswmd.arxml 
  /AUTOSAR/Os is used by ECU-C file D:\ECU_1_ecuc.arxml 
using ECU-C definition 
 
The misconfiguration can be detected because the module names are standardized, i.e. 
the <DEFINITION-REF> of a <MODULE-CONFIGURATION> always follows the rule 
/[MODULE-DEF-PACKAGE-NAME]/[standardized module name]. 
3.5.1 
Pre- and Recommended config sections 
DaVinci  DEV  in  general  does  not  evaluate  Pre-  and/or  Recommended  Module 
Configuration sections in the BSWMD or any other file. However, one exception exists for 
the  Os  where  a  preconfigured  OsCounter  is  set  as  an  Alarm’s  OsAlarmCounterRef  by 
default (see 4.5.1). 
3.6 
Synchronizing an ECU-C file 
Synchronizing an ECU-C file is necessary if the configuration of the RTE does not match 
to the configuration of the depending modules (see section 4 for a detailed description of 
2014, Vector Informatik GmbH 
Version: 1.13 
13 / 34 
 
 



ECU-C File Handling Technical Reference 
 
the parameters for each module). The synchronization process can be divided into several 
steps which will be explained in the following sections. 
3.6.1 
Step 1: Analysis of the RTE configuration in the workspace 
In  the  first  step  the  settings  of  the  workspace  (more  precisely,  the  ECU  project)  are 
analyzed  and  all  additionally  derived  attributes  are  calculated.  In  general,  there  are  two 
different categories of settings. 
The  first  category  (explicit  parameters)  includes  settings  which  are  directly  configured  by 
the user in DaVinci DEV or derived from this configuration because of standardized rules 
given  in  AUTOSAR’s  System  Template  Specification  chapter  “Harmonisation  between 
Upstream Templates and ECU Configuration”. 
The  second  category  (implicit  parameters)  includes  implementation  dependant  settings 
which are determined by the Rte generator and consists of those Os module configuration 
elements which are written by DaVinci DEV and are not visible to the user (see section 4.5 
for details). 
To  ensure  that  the  determined  configuration is  consistent the  corresponding  ECU-Project 
is checked for a correct design. If DaVinci DEV detects an error the dialog in Figure 3-2 is 
shown. 
 
 
Figure 3-2 ECU-Project is inconsistent 
In this case the implicit parameters won’t be available in the next steps. Depending on the 
next  actions  this  may  remove  already  existing  implicit  parameters  from  the  configuration 
although  this  was  not  intended. Therefore  the  dialog  is  shown  to  indicate  that  there  is  a 
problem which should be fixed if a correct Os configuration is needed. The design errors 
are displayed in the “Messages” tab and should be checked for a more detailed description 
of the problem. 
If DaVinci DEV did not detect any problems or the user wants to continue anyway, the Rte 
generator  is  called  which  determines  all  required  Os  elements.  Since  some  design 
constraints are currently not checked by DaVinci DEV additional checks are performed by 
the  Rte  generator.  The  dialog  in  Figure  3-3  is  shown  if  the  Rte  generator  aborted  and 
reported an error. The detailed error message is available in the “Code Generator Log” tab. 
2014, Vector Informatik GmbH 
Version: 1.13 
14 / 34 
 
 




ECU-C File Handling Technical Reference 
 
 
 
Figure 3-3 The Rte generator detected an inconsistent system design 
3.6.2 
Step 2: Comparison of workspace and ECU-C file 
If all parameters could be derived, the given ECU-C file is imported and the settings of the 
workspace are compared to the settings of the ECU-C file. If differences were detected the 
dialog in Figure 3-4 is shown. The user can then select whether the settings of the ECU-C 
file should be imported (direction “<<”), i.e. the ECU-Project should be changed according 
to the settings in the ECU-C file, or if the settings of the ECU-Project should be exported, 
i.e.  the  ECU-C  file  should  be  changed  according  to  the  settings  in  the  ECU-Project 
(direction  “>>”).  Remember  that  an  export  might  remove  existing  Os  elements  from  the 
ECU-C file if the ECU-Project is inconsistent but the previously shown dialog (Figure 3-2) 
was closed with “Yes” (“export anyway”). 
 
 
Figure 3-4 ECU-C-Synchronization dialog 
On the left side the dialog displays the timestamp of the last synchronization of the ECU-
Project, and on the right side the “last modified” timestamp of the ECU-C file is displayed. 
Since both the ECU-C file and the ECU-Project can be edited in parallel there’s no rule of 
thumb  to  decide  which  synchronization  direction  has  to  be  chosen  without  considering 
additional  information.  Therefore  the  “Details…”  button  shows  a  dialog  with  the  actual 
differences of both configurations. Section 3.6.5 describes the dialog in detail. 
2014, Vector Informatik GmbH 
Version: 1.13 
15 / 34 
 
 



ECU-C File Handling Technical Reference 
 
Chapter 5 shows some practical approaches, which makes it easier for the user to avoid 
errors  like  selecting  the  wrong  synchronization  direction  or  to  run  a  synchronization 
process even though it is not required to do so. 
Chapter 4 shows in details, which parameters are affected or relevant for DaVinci DEV. 
The next sections describe what happens if the user selects “import” or “export”. 
3.6.3 
Synchronization direction “import” 
If “import” is selected, the ECU-Project is changed according to the settings of the ECU-C 
file. If one of the modules Rte, Os, Com, NvM is not configured in the ECU-C file the user 
is asked if he wants to delete the corresponding settings in the ECU-Project as well or  if 
they should be kept as they are. This is useful if the user already added a task mapping in 
DaVinci DEV but did not yet configure the Os module. When the import has completed the 
new  ECU-Project  settings  are  analyzed  again  and  the  resulting  configuration parameters 
are  compared  to  the  ECU-C  file  settings. This  is  necessary  because  changes  of  the  Rte 
configuration  might  result  in  additional  changes  of  the  Com  or  Os  configuration.  If  this  is 
the case the user is asked if he wants to update the corresponding module configuration in 
the  ECU-C  file  or  not  (Figure  3-5).  Depending  on  the  user’s  role  he  might  be  allowed  to 
change  the  Os  or  Com  configuration  or  he  has  to  confer  with  the  responsible  person  at 
first. 
Again,  the  “Details…”  button  allows  to  further  investigate  the  actual  differences  between 
the ECU-Project’s implicit configuration and the settings from the ECU-C file. 
 
 
Figure 3-5 Module specific ECU-Configuration update dialog 
3.6.4 
Synchronization direction “export” 
If  “export”  is  selected,  the  ECU-C  file  is  changed  according  to  the  settings  of  the  ECU-
project. This means that the explicit parameters are written to the file. Then it is checked if 
other  module  configurations  have  to  be  updated  with  implicit  parameters,  e.g. 
ComCallbacks or Os elements. If this is the case, DaVinci DEV asks the user to decide if 
the corresponding module configuration in the ECU-C file should be updated or not (Figure 
3-5). 
Again,  the  “Details…”  button  allows  to  further  investigate  the  actual  differences  between 
the ECU-Project’s implicit configuration and the settings from the ECU-C file. 
3.6.5 
ECU-Configuration difference dialog 
The ECU-Configuration difference dialog helps the user to decide about his further actions 
whenever  the  configurations  of  the  ECU-Project  and  the  ECU-C  file  are  inconsistent.  It 
2014, Vector Informatik GmbH 
Version: 1.13 
16 / 34 
 
 






ECU-C File Handling Technical Reference 
 
may be opened from the ECU-C synchronization dialog described in section 3.6.2 as well 
as  the  dialogs  from  sections  3.6.3  and  3.6.4  which  are  displayed  for  each  module 
configuration. 
 
Figure 3-6 ECU-Configuration difference dialog 
The dialog displays the relevant module configurations and a status icon indicating if there 
are inconsistencies (
) or if the settings in the ECU-Project and the ECU-C file are equal 
(
)  or  equivalent  (
).  Values  which  are  not  set  in  the  ECU-Project  (either  explicit  or 
implicit parameters) are not displayed in the dialog unless it is required that these values 
have to be removed from the ECU-C file as well. 
If there are only small changes in a complex configuration the “Show conflicts only” option 
may  be  used  to  reduce  the  displayed  parameters  to  those  which  are  considered 
inconsistent. 
Figure 3-6 shows an example where a new task “EventTask” was added in DaVinci DEV 
and  a  Runnable  was  moved  from  “ControlTask”  to  the  new  task.  The  SensorTask’s 
attribute “TaskType” is displayed as equivalent because “AUTO” is the default value if no 
specific attribute value is set in the ECU-C file. 
2014, Vector Informatik GmbH 
Version: 1.13 
17 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4  ECU-Configuration parameters 
The following sections list the parameters and/or containers which are read and/or written 
by DaVinci DEV. All other parameters/containers in the ECU-C file do not affect the RTE. 
They can be changed in the ECU-C file without need of synchronizing the workspace. 
 
For some parameters it is allowed that the ECU-Project and the ECU-C file contain 
different values. These parameters and the corresponding rules are given in the following 
sections as well. Remember these values are not displayed in the difference dialog if the 
ECU-Project’s parameter has no specific value. 
4.1 
Vendor Specific Configuration Parameters 
Vendor  specific  configuration  parameters  for  Microsar  Modules  are  specified  in  each 
module’s  BSWMD  file  which  is  named  <Modulename>_bswmd.arxml.  These  parameters 
are marked with (MICROSAR) in the following sections. 
4.2 
Rte module 
4.2.1 
Parameters 
Rte module configuration 
Parameter 
Read/Write 
 
RteVfbTrace 
r/w 
 
RteVfbTraceFunction 
r/w 
 
RteA2LVersion (MICROSAR) 
r/w 
 
RteXcpEventSupport (MICROSAR) 
r/w 
 
RteMeasurementSupport 
r/w 
 
RteCalibrationSupport 
r/w 
 
RteCalibrationBufferSize 
r/w 
 
RteOptimizationMode 
r/w 
 
RteTaskConfiguration (MICROSAR) 
r/w 
 
  RteTaskUsesSchedule (MICROSAR) 
r/w 
 
  RteTaskRef (MICROSAR) 
r/w 
 
SwComponentInstance/ 
r/w 
 
  ImplementationRef 

 
2014, Vector Informatik GmbH 
Version: 1.13 
18 / 34 
 
 


ECU-C File Handling Technical Reference 
 
  ServiceComponentPrototypeRef 

 
  SoftwareComponentPrototypeRef 

 
  ExclusiveAreaImplementation 
r/w 
 
  NvRamAllocation/ 
r/w 
 
    SwNvRamMappingReference 
r/w 
 
    NvmBlockRef 
r/w 
 
  RunnableEntityMapping/ 
r/w 
 
    ActivationOffset 
r/w 
 
    PositionInTask 
r/w 
 
    RTEEventRef (resolved to Runnable) 
r/w 
 
    MappedToTaskRef 
r/w 
 
    RteCyclicTriggerImplementation (MICROSAR) 
r/w 
 
ComponentTypeCalibration/ 
 
 
  CalibrationSupportEnabled 
r/w 
 
Table 4-1 Rte configuration parameters 
These settings are configured in DaVinci DEV at ECU-Project level.  
Please note: 
•  The implementation selection is not read since DaVinci DEV always assumes that 
only one implementation per atomic component type exists. 
•  RteCyclicTriggerImplementation  is  not  visible  in  DaVinci  DEV  and  cannot  be 
modified. 
•  RteTaskConfiguration  settings  are  displayed  in  the  Os  section  in  the  ECU-
Configuration difference dialog (3.6.5). 
4.3 
SchM module 
4.3.1 
General 
The SchM module configuration is never changed by DaVinci DEV; it is only used as the 
read-only  master  configuration  for  RunnableEntityMappings  of  ServiceComponentTypes 
and the “Role” attribute of an OsTask. 
2014, Vector Informatik GmbH 
Version: 1.13 
19 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.3.2 
Parameters 
SchM module configuration 
Parameter 
Read/Write 
 
SchMMainFunctionMapping/ 

 
  SchMMainFunctionSymbol 

 
  SchMBswActivationOffset 

 
  SchMMappedToTask 

 
  SchMPositionInTask 

 
Table 4-2 SchM configuration parameters 
4.3.3 
Rte 
The SchM module configuration contains a task mapping for BSW functions similar to the 
RTEEvent  mapping  in  the  Rte  module  configuration.  If  these  BSW  functions  are 
represented by a Runnable of a corresponding ServiceComponentType the mapping of its 
RTEEvents to an OsTask has to be added to the Rte module configuration. 
If  DaVinci  DEV  detects  a  SchMMainFunctionMapping  for  a  Runnable2  of  a 
ServiceComponentType 
used 
in 
the 
ECUProject, 

corresponding 
virtual 
RunnableEntityMapping is derived automatically. The mapping is called virtual because it 
is  only  displayed  in  the  ECU-Configuration difference dialog  and not  automatically  added 
to  the  Rte  ECU-Configuration  section. This  has  to  be  done  by  the  usual  synchronization 
mechanism, i.e. the new RunnableEntityMapping has to be imported in DaVinci DEV and 
exported to the Rte ECU-Configuration section. 
If  the  Runnable  of  the  ServiceComponentType  is  already  mapped  to  another  OsTask  in 
DaVinci DEV, the mapping will be adapted to ensure both SchM and the Rte use the same 
OsTask. As the actual position of a runnable within a task is not used by the Rte generator 
in  this  context,  DaVinci  DEV  does  not  modify  PositionInTask  if  it  differs  from 
SchMPositionInTask. 
Whenever DaVinci DEV adds a virtual RunnableEntityMapping or modifies the OsTask of 
an existing RunnableEntityMapping a log message is written to the Action Log. 
 
4.3.4 
Os 
DaVinci DEV sets the “Role” attribute of an OsTask to “BSW Scheduler” if it is referenced 
by any SchMMainFunctionMapping container. 
                                            
2 the Runnable is found by matching its name with the value of SchMMainFunctionSymbol 
2014, Vector Informatik GmbH 
Version: 1.13 
20 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.4 
Com module 
4.4.1 
Parameters 
Com module configuration 
Parameter 
Read/Write 
 
ComSignal/ 

 
  ShortName 
(r) 
 
  ComDataInvalidAction 

 
  ComInvalidNotification 

 
  ComSignalDataInvalidValue 

 
  SystemTemplateSystemSignalRef 
(r)/w 
 
  ComSignalInitValue 

 
  ComErrorNotification 

 
  ComNotification 

 
  ComTimeoutNotification 

 
  ComTimeoutFactor 

 
  ComSignalType 

 
  ComFilter/ 
 
 
    ComFilterAlgorithm 

 
    ComFilterMask 

 
ComSignalGroup/ 

 
  ShortName 
(r) 
 
  ComDataInvalidAction 

 
  ComErrorNotification 

 
  ComInvalidNotification 

 
  ComNotification 

 
  ComTimeoutFactor 

 
  ComTimeoutNotification 

 
  SystemTemplateSignalGroupRef 
(r)/w 
 
2014, Vector Informatik GmbH 
Version: 1.13 
21 / 34 
 
 


ECU-C File Handling Technical Reference 
 
  ComGroupSignal/ 
(r)/w 
 
    ShortName 
(r) 
 
    ComSignalDataInvalidValue 

 
    ComSignalInitValue 

 
    ComSignalType 

 
    SystemTemplateSystemSignalRef 
(r)/w 
 
    ComFilter/ 
 
 
      ComFilterAlgorithm 

 
      ComFilterMask 

 
Table 4-3 Com configuration parameters 
For simplicity, only the term “ComSignal” is used in the following explanation but the basic 
principle is true for ComSignalGroups, too. 
DaVinci DEV assumes that the same communication database has been used to setup the 
workspace  as  well  as  the  ComSignals  in  the  ECU-C  file  (which  is  done  by  the  BSW 
Configuration  Tool  by  importing  e.g.  a  dbc  file  or  an AUTOSAR  ECU  Extract  of  System 
Description). Therefore, DaVinci DEV does not import ComSignals. 
“(r)” means that either the ShortName or the SystemTemplateSignalRef is read to identify 
the  ComSignal  and  store  its  name  to  be  able  to  use  correct  ComSignal  handles  in  the 
generated Rte code. 
Please see section 4.8 for details about ComSignals and usage of their symbolic handles. 
4.4.2 
Equivalent parameter values 
Com module configuration 
Parameter 
Equivalence rule 
ComSignal/ 
 
  ComDataInvalidAction 
Parameter values “NONE” and “” (undefined attribute value) are equivalent 
  ComInvalidNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComSignalInitValue 
ECU-Project parameter is not set (InvalidAction is not set to “Replace”) 
  ComErrorNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComTimeoutNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
2014, Vector Informatik GmbH 
Version: 1.13 
22 / 34 
 
 


ECU-C File Handling Technical Reference 
 
  ComTimeoutFactor 
ECU-C file value is greater than 0 but less than ECU-Project value 
Starting  with  DaVinci  Developer  3.0  SP3  this  depends  on  the  workspace 
setting “SWC Alive Timeout overrides ComSignal” (see 4.4.2.1) 
ComSignalGroup/ 
 
  ComDataInvalidAction 
Parameter values “NONE” and “” (undefined attribute value) are equivalent 
  ComErrorNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComInvalidNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComTimeoutFactor 
ECU-C file value is greater than 0 but less than ECU-Project value 
Starting  with  DaVinci  Developer  3.0  SP3  this  depends  on  the  workspace 
setting “SWC Alive Timeout overrides ComSignal” (see 4.4.2.1) 
  ComTimeoutNotification 
ECU-Project parameter is set but ECU-C file contains a non-Rte callback 
  ComGroupSignal/ 
 
    ComSignalInitValue 
ECU-Project parameter is not set (InvalidAction is not set to “Replace”) 
Table 4-4 Com equivalent parameter value rules 
If  a  ComSignal’s  callback  is  already  set  to  a  non-Rte  callback  this  configuration  is 
accepted  but  a  message  is  displayed  which  contains  the  ComSignal  name  and  the 
callback name. In this configuration the user is in charge to ensure that the Rte’s callback 
function is called. 
4.4.2.1 
ComTimeoutFactor 
Depending  on  the  design  approach,  the  ComTimeoutFactor  may  be  specified  by  the 
communication  design  or  should  be  updated  based  on  the  software  design.  To  support 
both  strategies,  a  workspace  specific  setting  allows  specifying  how  to  synchronize  the 
ComTimeoutFactor:  “never”,  only  if  the  value  of  the  software  design  is  lower  than  the 
current ComTimeoutFactor value or “always”. 
4.5 
Os module 
4.5.1 
Parameters 
The  column  “Category“  of  the  following  table  specifies  if  the  user  can  edit  the 
corresponding parameter (“DEV“) or if it is automatically derived by the Rte code generator 
(“Rte generator“). 
Os module configuration 
Parameter 
Read/Write 
Category 
2014, Vector Informatik GmbH 
Version: 1.13 
23 / 34 
 
 


ECU-C File Handling Technical Reference 
 
OsAlarm/ 

Implicit 
  OsAlarmAccessingApplication 

Implicit 
  OsAlarmAction/ 
 
Implicit 
    OsAlarmActivateTask/ 
 
Implicit 
      OsAlarmActivateTaskRef 

Implicit 
    OsAlarmSetEvent/ 
 
Implicit 
      OsAlarmSetEventRef 

Implicit 
      OsAlarmSetEventTaskRef 

Implicit 
  OsAlarmCounterRef 

Explicit 
OsEvent/ 

Implicit 
  OsEventMask 

Implicit 
OsApplication/ 

Explicit / Implicit 
  OsTrusted 
r/w 
Explicit / Implicit 
  OsAppAlarmRef 

Implicit 
  OsAppResourceRef 

Implicit 
  OsAppTaskRef 

Implicit 
  OsApplicationTrustedFunction/ 
 
Implicit 
    OsTrustedFunctionName 

Implicit 
    OsApplicationParams (MICROSAR) 

Implicit 
    OsApplicationReturnType (MICROSAR) 

Implicit 
    OsApplicationGenerateStub (MICROSAR) 

Implicit 
OsCounter 

Explicit 
OsResource/ 

Implicit 
  OsResourceProperty 

Implicit 
OsTask/ 
r/w 
Explicit 
  OsTaskPriority 
r/w 
Explicit 
  OsTaskSchedule 
r/w 
Explicit 
2014, Vector Informatik GmbH 
Version: 1.13 
24 / 34 
 
 


ECU-C File Handling Technical Reference 
 
  OsTaskTYPE (MICROSAR) 
r/w 
Explicit 
  OsTaskActivation 

Implicit 
  OsTaskAutostart/ 
 
Implicit 
    OsTaskAppModeRef 
r/w 
Implicit 
  OsTaskAppMode 

Implicit 
  OsTaskEventRef 

Implicit 
  OsTaskResourceRef 

Implicit 
  OsTaskAccessingApplication 

Explicit / Implicit 
  AdminData/ 
 
 
    DV_TaskTimingPreConfig (DaVinci DEV) 
r/w 
Explicit 
    DV_TaskTimingCycleTime (DaVinci DEV) 
r/w 
Explicit 
    DV_TaskTimingOffset (DaVinci DEV) 
r/w 
Explicit 
Table 4-5 Os module parameters 
Most  of  the  Os  objects  are  implicit,  i.e.  not  directly  visible  and  editable  in  DaVinci  DEV.  
Only OsTask and OsApplication can be changed by the user. All other objects (OsAlarm, 
OsEvent,  OsResource)  are  implicit.  They  reflect  the  implementation  of  the  MICROSAR 
RTE.  
The OsApplication is classified as “Explicit / Implicit”, because an additional implicit special 
OsApplication named “Rte” might be required beside the explicitly defined OsApplications. 
The  existence  of  this  implicit  OsApplication  depends  on  runnable  and  task  mapping 
configuration. 
Depending on the Os module version the configuration parameter OsTaskTYPE is stored 
in  different  configuration  container  layouts; therefore  the  module’s BSWMD file  has to  be 
configured at the ECU-Project to ensure that the parameter is written in the correct layout. 
All implicit Os elements are prefixed with “Rte_”. Their name must not be changed.  
OsCounter  and  OsAlarmCounterRef  are  only  exported  if  a  BSWMD  is  configured  which 
contains  a  pre-config  section  with  an  OsCounter.  The  OsAlarmCounterRef  is  set  to  this 
OsCounter by default but may be changed by the user in the Os configuration tool. 
The  optional  TaskTiming  configuration  is  used  by  DaVinci  DEV  to  check  for  consistent 
cyclic runnable triggers and is not evaluated by the Os module. 
2014, Vector Informatik GmbH 
Version: 1.13 
25 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.5.2 
Equivalent parameter values 
Os module configuration 
Parameter 
Equivalence rule 
OsAlarm/ 
 
  OsAlarmCounterRef 
No Os-BSWMD file is referenced or the user has configured a specific 
OsCounter. 
OsTask/ 
 
  OsTaskTYPE (MICROSAR) 
ECU-C  file  does  not  contain  a  value  and  no  Os-BSWMD  file  is 
referenced by the ECU-Project which contains the parameter definition 
  OsTaskAutostart 
ECU-Project parameter is not set 
Table 4-6 Os equivalent parameter value rules 
4.6 
NvM module 
4.6.1 
Parameters 
NvM module configuration 
Parameter 
Read/Write 
Category 
NvmBlockDescriptor/ 
r/w 
Explicit 
  NvmNvBlockLength 

Implicit/Explicit 
  NvmRamBlockDataAddress 

Implicit 
  NvmRomBlockDataAddress 

Implicit 
  NvmNvramBlockIdentifier 
r/w 
Explicit 
  NvmBlockUseSyncMechanism 

Implicit 
  NvmWriteRamBlockToNvCallback 

Implicit 
  NvmReadRamBlockFromNvCallback 

Implicit 
Table 4-7 NvM configuration parameters 
To  be  able  to  do  a  memory  mapping  in  DaVinci  DEV,  NvMBlocks  are  imported  from  an 
ECU-C  file.  However,  other  attributes  cannot  be  changed  and  the  above  mentioned 
attributes  are  automatically  derived  from  an  existing  memory  mapping  during  ECU-C-
Synchronization. 
2014, Vector Informatik GmbH 
Version: 1.13 
26 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.6.2 
Equivalent parameter values 
NvM module configuration 
Parameter 
Equivalence rule 
NvmBlockDescriptor/ 
 
  NvmNvBlockLength 
ECU-Project  parameter  is  not  set  (no  MemoryMapping  for 
NvMBlock) 
  NvmRamBlockDataAddress 
ECU-Project  parameter  is  not  set  (no  MemoryMapping  for 
NvMBlock) 
  NvmRomBlockDataAddress 
ECU-Project  parameter  is  not  set  (no  MemoryMapping  for 
NvMBlock) 
  NvmNvramBlockIdentifier 
ECU-Project  parameter  is  not  set  but  the  ECU-C  file  contains  a 
value 
  NvmBlockUseSyncMechanism 
ECU-Project  parameter  is  not  set  to  “true”  or  the  Nvm  BSWMD 
does not specify this parameter 
  NvmWriteRamBlockToNvCallback 
ECU-Project parameter is set but ECU-C file contains a non-Rte 
callback or the Nvm BSWMD does not specify this parameter 
  NvmReadRamBlockFromNvCallback  ECU-Project parameter is set but ECU-C file contains a non-Rte 
callback or the Nvm BSWMD does not specify this parameter 
Table 4-8 NvM equivalent parameter value rules 
4.7 
Board 
4.7.1 
Parameters 
Board module configuration 
Parameter 
Read/Write 
Category 
BoardGeneral/ 
 
 
  BoardAtomicVariableAccess (MICROSAR) 

(Explicit) 
  BoardEnableSnvPrefixes (MICROSAR) 

(Explicit) 
Table 4-9 Board configuration parameters 
The parameters are marked as “(Explicit)” because it is not visible in DaVinci DEV but the 
Rte generator adapts the Rte code according to the parameter’s value. 
2014, Vector Informatik GmbH 
Version: 1.13 
27 / 34 
 
 


ECU-C File Handling Technical Reference 
 
4.7.2 
Equivalent parameter values 
Board module configuration 
Parameter 
Equivalence rule 
BoardGeneral/ 
 
  BoardAtomicVariableAccess 
ECU-C file does not contain a value and ECU-Project parameter is set 
   (MICROSAR) 
to default value “Atomic16BitAccess” 
  BoardEnableSnvPrefixes 
ECU-C file does not contain a value and ECU-Project parameter is set 
  (MICROSAR) 
to value “false” 
Table 4-10 Board equivalent parameter value rules 
4.8 
ComSignals and ComSignalGroups 
Since the Rte utilizes the Com module to transfer application data over the communication 
bus  it  has  to  know  the  mapping  of  SystemSignals  to  ComSignal  handles  defined  by  the 
Com  module.  If  the  handles  are  completely  different  or  even  worse  existing  handles  are 
used for the wrong SystemSignal the result may be a simple compile error or in the worst 
case the problem is only visible at run time. In general, it is not possible to always use the 
default approach and use the SystemSignal’s name as the ComSignal handle because the 
Rte  has  to  support  Gateway  signals  (receive)  and  FanOut  signals  (write).  In  this  case, 
more  than  one  ComSignal  exists  for  each  SystemSignal  and  the  Rte  has  to  call  the 
Com_SendSignal-API for each of these ComSignals with the correct handle.   
To  ensure  that  the  Rte  knows  about  the  correct  ComSignal  handles,  there  are  different 
approaches  depending  on  the  AUTOSAR  version  and  the  source  of  the  communication 
data. 
4.8.1 
dbc files 
The signals in the dbc file are imported as SystemSignals and the ComSignal handles are 
derived from their name. In case of Gateway/FanOut signals the dbc file contains signal 
names following the rule <SystemSignal>_ISig_<number> to be able to identify the original 
SystemSignal and to provide a unique name for each of the ComSignals on the different 
communication buses. 
 
When such a dbc file is imported in DaVinci DEV one SystemSignal is created for each 
unique SystemSignal name and the complete signal name, e.g. SigMyData_ISig_0, is 
internally stored to be able to find the correct ComSignal during ECU-C-Synchronization. 
 
NWD creates dbc files with these signal names if the export option “Create GENy 
compatible signal names” is activated. 
4.8.2 
ECU-Extract 
An ECU-Extract is imported as it is, i.e. SystemSignals are imported as SystemSignals 
and no special naming rules apply for these signals. 
 
2014, Vector Informatik GmbH 
Version: 1.13 
28 / 34 
 
 


ECU-C File Handling Technical Reference 
 
If AUTOSAR 3.0 is used there’s one limitation: The AUTOSAR ShortName path of a 
SignalToIPDUMapping has to follow the rule: 
DaVinci/PKG_Cluster<ClusterName>/<PDUName>/<SystemSignalName>_S for 
Signals 
DaVinci/PKG_Cluster<ClusterName>/<PDUName>/<SystemSignalName>_SG 
for SignalGroups 
for CAN <PDUName> has to be the name of the CAN frame 
 
ECU-Extracts of DaVinci DEV and NWD follow this rule. 
If an ECU-Extract is used with a different package structure and/or naming of the relevant 
elements it is usually not possible to match the ComSignals of the ECU-C file with the 
SystemSignals of DaVinci DEV’s workspace. 
4.8.3 
AUTOSAR 2.1 
Since there is no explicit relation of a ComSignal to the corresponding SystemSignal the 
ECU-Synchronization identifies matching pairs of ComSignal/SystemSignal by their name. 
4.8.4 
AUTOSAR 3.x 
With AUTOSAR 3.0 an indirect relation from ComSignal to the SystemSignal was 
introduced. The ComSignal references a SignalToIPduMapping which itself eventually 
references the SystemSignal. 
To be able to resolve this reference from the ECU-Configuration into the ECU-Extract, the 
naming rule described in section 4.8.2 has to be fulfilled. 
 
4.8.5 
Relevant ComSignals  
It is important to remember that the Rte does not need to know all ComSignals and their 
handles. Only those SystemSignal/ComSignal relations are relevant which are used by 
applications, i.e. where a data mapping of DataElements to SystemSignals exists. If 
attributes of other ComSignals or attributes which are not handled by DaVinci DEV are 
modified it is not necessary to perform an ECU-C-Synchronization. 
To support the dbc based Com module configuration in a Com configurator like GENy, 
DaVinci DEV derives certain ComSignal attributes from the ECU-Extract because they are 
not contained in a dbc file, e.g. ComSignalType. These attributes are written to the ECU-C 
file during ECU-C-Synchronization. This causes modification of ComSignals which are not 
data mapped to a DataElement. 
4.8.6 
Callbacks 
Depending  on  the  configuration  the  Rte needs  to  be  informed  by  the  Com  module about 
certain events, e.g. when a signal is received. The Rte’s callback function name is set by 
DaVinci DEV at the corresponding ComSignal if the configuration parameter is not set. In 
case there is already a callback configured DaVinci DEV displays a corresponding warning 
message  in  the  Messages  window  with  all  ComSignals,  configured  callbacks  and 
additionally  needed  callbacks.  In  this  scenario  the  user  has  to  call  the  Rte  function 
manually. 
 
2014, Vector Informatik GmbH 
Version: 1.13 
29 / 34 
 
 


ECU-C File Handling Technical Reference 
 
Message Details 
 
ECUProject ECU1 contains the following ComSignals/ComSignalGroups with non-Rte 
callbacks: 
 
ComSignal Com_Signal_Temp_EnvData: 
 
CallbackName 
Needed Rte callback: Rte_COMCbk_Com_Signal_Temp_EnvData 
Assigned callback  : Custom_Callback_Com_Signal_Temp_EnvData 
 
The same mechanism is used for Nvm callbacks. 
2014, Vector Informatik GmbH 
Version: 1.13 
30 / 34 
 
 



ECU-C File Handling Technical Reference 
 
5  Best practices 
Since the process of ECU-Configuration is rather complex you should follow some basic 
rules given in this chapter. These rules should be seen as a guideline to avoid 
unnecessary ECU-C-Synchronization processes in DaVinci DEV and nevertheless ensure 
a consistent overall configuration. 
5.1 
Always work on the latest communication databases 
Always ensure that you are working on the latest communication databases in all tools. It 
is  often  a  problem  that  updated  dbc  files  are  imported  in  a  BSW  configuration  tool  like 
GENy but not in DaVinci DEV. If both tools work on a different communication model it is 
very likely that they derive a different set of ComSignals and report various errors. 
 
Example Error Message: 
  ComSignal 
with 
an 
invalid 
SystemSignal 
reference 
/DaVinci/PKG_ClusterCanA/PKG_PDU/Frame1/Signal1_S,  the  according 
ISignalToIPDUMapping object could not be identified. 
 
 
The given example shows an error message which is displayed if the ECU-C file contains 
a ComSignal which is not known in DaVinci DEV, i.e. the Com configuration was updated 
by  the  Com  configurator  based  on  a  certain  communication  database  but  DaVinci  DEV 
does not have the same information available. 
Another  reason  for  this  error  message  is  the  fact  that  DaVinci  DEV  can  only  work  with 
ECU-C files based on ECU-Extracts if the ECU-Extract follows a naming rule concerning 
ISignalToIPDUMappings (see section 4.8). 
5.2 
Do not edit the same module configuration in different tools at the same time 
Since several tools may edit the same module configuration (e.g. OsTasks can be edited in 
DaVinci  DEV  and  third  party  BSW  configuration  tool),  it  is  not  wise  to  use  both  tools  in 
parallel,  especially  if  some  of  the  configuration  settings  are  automatically  derived  from 
another  module’s  configuration.  The  decision  what  to  do  in  DaVinci  DEV,  i.e.  choose 
„import“  or  „export“  during  ECU-C-Synchronization,  becomes  much  easier  if  the  module 
configurations  are  edited  exclusively  by  one  tool  at  a  time.  So  you  might  add  a  new 
OsTask  in  DaVinci  DEV,  synchronize  the  ECU-C  file,  change  to  BSW  configuration  tool 
and  add  another  OsTask  for  a  non-Rte  purpose,  save  the  ECU-C  file,  switch  back  to 
DaVinci  DEV,  synchronize  the  ECU-C  file  again  and  add  some  more  OsTasks  for 
additional runnables. You should not add these new OsTasks in both tools in parallel, since 
either  the  OsTasks  defined  in  DaVinci  DEV  or  the  OsTaks  defined  in  the  BSW 
configuration tool will be lost when running the synchronization. 
If  you execute  external  generators  and/or  configurators from  DaVinci  DEV’s  generator  or 
configurator  lists  you  may  enable  “Options/Settings/ECU  generation/Automatic 
2014, Vector Informatik GmbH 
Version: 1.13 
31 / 34 
 
 



ECU-C File Handling Technical Reference 
 
synchronization  of  ECU  Configuration  file”.  In  this  case  the  ECU-C  file  is  always 
synchronized  before  the  executable  is  run  and  after  it  has  been  closed.  Although  this 
ensures that the ECU-Project and the ECU-C file are always in a consistent state, it might 
be  better  to  not  use  this  option  and  explicitly  synchronize  the  ECU-C  file  to  avoid 
unnecessary  and  probably  time  consuming  synchronizations  when  you  edit  configuration 
parameters 
which 
are 
not 
relevant  for 
DaVinci 
DEV 
and 
the 
executed 
generator/configurator. 
As  explained  in  3.4  Vector  tools  implement  a  mechanism  to  ensure  that  the  ECU 
configuration is editable in only one tool at the same time. So you don’t have the problems 
mentioned above when just working with the Vector tools. 
5.3 
Ensure that all tools use the same max. SHORT-NAME length 
Although AUTOSAR  specifications  up  to  releases  3.0.6 and  3.1.4  specify  that a  SHORT-
NAME  must not  exceed  the  length  of 32  characters,  DaVinci  DEV  supports  an extended 
length of up to 128 characters. If this setting is enabled (Options/Settings/AUTOSAR XML) 
it has to be ensured that all other tools support this extension, too. If this is not the case 
configuration elements won’t be found during ECU-C-Synchronization and will be created 
a second time if the name is longer than 32 characters. 
Starting  with  AUTOSAR  releases  3.0.7,  3.1.6  and  3.2,  SHORT-NAMEs  with  up  to  128 
characters are allowed by the standard. 
5.4 
ECU-C files have to be valid according to the AUTOSAR schema 
DaVinci  DEV  validates  the  ECU-C  file  against  the  corresponding  AUTOSAR  schema 
before it is imported. If the file is not valid the XML parser error is displayed in a dialog and 
the ECU-C-Synchronization is aborted. 
 
Figure 5-1 Validation of the ECU-C file failed 
2014, Vector Informatik GmbH 
Version: 1.13 
32 / 34 
 
 


ECU-C File Handling Technical Reference 
 
5.5 
Configuration elements must have unique SHORT-NAMEs 
To be able to uniquely identify a configuration element all elements of the same hierarchy 
level must have unique SHORT-NAMEs. If this is not the case references within the ECU-
C file may point to several different elements which makes the configuration inconsistent. 
Since  this  constraint  is  not  checked  by  the  XML  schema,  an  additional  check  is 
implemented  in  DaVinci  DEV  and  an  error  message  is  printed  in  the  „Action  Log“  tab  if 
such an error occurred. 
2014, Vector Informatik GmbH 
Version: 1.13 
33 / 34 
 
 


ECU-C File Handling Technical Reference 
 
6  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector-informatik.com 
 
2014, Vector Informatik GmbH 
Version: 1.13 
34 / 34 
 
 

24 - TechnicalReference_UserDefinedAttributeExport

Microsoft Word - TechnicalReference_UserDefinedAttributeExport.doc

25 - TechnicalReference_UserDefinedAttributeExport_ind

Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11

26 - TechnicalReference_UserDefinedAttributeExports


 
 
 
 
 
 
 
 
 
 
 
 
User-defined attribute XML-export 
Technical Reference 
 
 
 
 
Version 1.3 
 
 
 
 
 
 
Authors: 
Michael Hoffmann, Andreas Claus 
Version: 
1.3 
Status: 
released (in preparation/completed/inspected/released) 
 
 
 


User-defined attribute XML-export Technical Reference 
 
History 
 
Author 
Date 
Version  Remarks 
Hn 
2007-02-02 
1.0 
Document released 
Cs 
2007-11-28 
1.1 
New document template; minor corrections 
Hn 
2008-02-08 
1.2 
Document updated 
Cs 
2012-04-11 
1.3 
DCF workspaces added; minor corrections 
 
Contents 
1
Overview ................................................................................................................... 3
1.1
Terms and Acronyms .................................................................................. 3
2
User-defined attributes in DaVinci .......................................................................... 4
2.1
Creating user-defined attribute definition .................................................... 4
2.2
User-defined attribute usage ....................................................................... 5
2.3
Creating the XML-export ............................................................................. 6
3
Design object reference ........................................................................................... 7
4
Attribute definition resolution ................................................................................. 8
4.1
Reference of global attribute definition values ............................................. 8
4.2
Reference of local attribute value ................................................................ 9
5
DCF Workspaces .................................................................................................... 10
5.1
Global attribute definition file ..................................................................... 10
5.2
Loading attribute definitions ...................................................................... 10
6
Contact .................................................................................................................... 11
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
1   Overview 
With  the  DaVinci  Developer  2.1  and  later  user-defined  attribute  definitions  can  be 
exported. This document describes the usage of the exported XML file format. 
1.1  Terms and Acronyms 
Term 
Definition 
DaVinci DEV 
DaVinci Developer 
AR 
AUTOSAR – Automotive Open System Architecture 
GUI 
Graphical user interface 
DCF 
DaVinci configuration file workspace 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 



User-defined attribute XML-export Technical Reference 
 
2  User-defined attributes in DaVinci 
DaVinci DEV are allows the definition of user-defined attributes for certain design elements 
visible within the GUI. 
The  set  of  design  elements  which  are  providing  the  definition  of  user-defined  attributes 
depends on the tool version. 
2.1  Creating user-defined attribute definition 
To create a user-defined attribute definition open the workspace global attribute definition 
table available on the main menu ‘View  Attribute Definition…’. 
Each  user-defined  attribute  is  related  to  a  DaVinci  object  type  and  must  have  a  name 
which is unique in the scope of the attribute definition table. 
The  definition  of  minimum,  maximum,  and  default  value  depends  on  the  selected  value 
type 
 
Figure 1: Definition of user-defined attribute 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 



User-defined attribute XML-export Technical Reference 
 
2.2  User-defined attribute usage 
Attribute  definitions  can  be  used  at  certain  design  objects  of  the  workspace.  For  each 
attribute  which  is  defined  within  the  global  attribute  table  and  associated  with  the  object 
type of the design object, a local value definition can be specified.  
These values are specific for each design object and are available in the properties dialog 
of the design object. 
A  design  object  can  only  use  those  user-defined  attributes  which  are  defined  within  the 
global attribute definition table. 
 
Figure 2: Definition of a local value of a user-defined attribute 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 



User-defined attribute XML-export Technical Reference 
 
2.3  Creating the XML-export 
The  export  of  user-defined  attributes  is  always  related  to  a  preceded  export  of  design 
elements. The export can be used with all supported AR versions. 
To create the XML export, select the appropriate design element within DaVinci DEV and 
choose the ‘XML Export…’ command from the context menu. 
The  export  dialog  provides  an  option  ‘Export  user-defined  attributes’.  If  this  option  is 
selected  an  additional  XML  output  file  will  be  created.  The  name  of  the  XML  file  is 
automatically  created  by  using  the  name  of  the  AR-XML  output  file  plus  the  extension 
‘_gen_attr’ (e.g. ‘System_gen_attr.xml’). 
 
 
Figure 3: User-defined attribute export option for XML-exports 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
3  Design object reference 
The design object reference clarifies in which way a certain design object is related to the 
user-defined attribute definition within the attribute export file. 
An AR design object is referenced by an AR reference which contains the package path to 
the SHORT_NAME attribute of the referenced AR object.  
This reference is stored within the Reference attribute of the ARObjectReference tag 
within the user-defined attribute export XML file. 
Beside the AR reference the ARObjectReference tag also includes the XML tag of the 
referenced AR element within its Type attribute. 
E.g.  for  a  software  component  type  ‘AP_MySWC’  following  reference  information  is 
exported: 
User-defined attribute export file: 
 
  <ObjectAttributeReference ObjectType="ComponentType"> 
    <ARObjectReference  
Type="APPLICATION-SOFTWARE-COMPONENT-TYPE" 
Reference="/ComponentType/AP_MySWC"> 
</ARObjectReference> 
…. 
  </ObjectAttributeReference> 
 
AR-export file: 
 
<AUTOSAR> 
  <TOP-LEVEL-PACKAGES> 
    <AR-PACKAGE> 
      <SHORT-NAME>ComponentType</SHORT-NAME> 
      <ELEMENTS> 
        <APPLICATION-SOFTWARE-COMPONENT-TYPE> 
          <SHORT-NAME>AP_MySWC</SHORT-NAME> 
…. 
        </APPLICATION-SOFTWARE-COMPONENT-TYPE> 
      </ELEMENTS> 
    </AR-PACKAGE> 
  </TOP-LEVEL-PACKAGES> 
</AUTOSAR>  
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
4  Attribute definition resolution 
The  attribute  definition  resolution  shows  how  a  global  user-defined  attribute  definition  is 
referenced by a certain design object.  
4.1  Reference of global attribute definition values 
If a design object doesn’t define a local value that is different from the global default value 
definition  the  user-defined  attribute  export  will  only  export  the  reference  to  the  relevant 
attribute  definition  table.  This  reference  (AttributeDefinitionTableRef)  contains  a 
Version and an ID attribute which uniquely identifies the relevant attribute definition table 
of the item (see ‘AttributeDefinitionTableRef’ of the example below). 
By using the ObjectType attribute information of the ObjectAttributeReference tag 
the  set  of  relevant  attribute  definitions  for  this  item  type  can  be  identified  (e.g. 
ComponentType’). 
User-defined attribute export file: 
 
<AttributeDefinition> 
  <AttributeDefinitionTable Version="1.0" ID="{932D3FD0-2F6C-49BF-80CB-D1C3756D3868}"
    <Attribute Name="MySWCEnum" ObjectType="ComponentType"> 
      <ENUM Default="Enum2"> 
        <EnumValue Value="Enum1"></EnumValue> 
        <EnumValue Value="Enum2"></EnumValue> 
        <EnumValue Value="Enum3"></EnumValue> 
      </ENUM> 
    </Attribute> 
  </AttributeDefinitionTable> 
 
  <ObjectAttributeReference ObjectType="ComponentType"> 
 
<ARObjectReference  
    Type="APPLICATION-SOFTWARE-COMPONENT-TYPE" 
    Reference="/ComponentType/AP_MySWC"> 
</ARObjectReference> 
 
<AttributeDefinitionTableRef   
    Version="1.0"  
    ID="{932D3FD0-2F6C-49BF-80CB-D1C3756D3868}"

</AttributeDefinitionTableRef> 
 
  </ObjectAttributeReference> 
</AttributeDefinition> 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
4.2  Reference of local attribute value 
Each  design  object  may  define  a  local  value  for  the  user-defined attributes. These  value 
definitions 
are 
exported 
with 
the 
AttributeValue 
tag 
within 
each 
ObjectAttributeReference  tag.  This  tag  contains  a  Name  attribute  which  uniquely 
identifies  a  single  attribute  within  the  attribute  definition  table  (e.g.  the  attribute 
MySWCEnum’). The Value attribute holds the local value of the design object. 
User-defined attribute export file: 
 
  <ObjectAttributeReference ObjectType="ComponentType"> 
    <ARObjectReference  
        Type="APPLICATION-SOFTWARE-COMPONENT-TYPE" 
         Reference="/ComponentType/AP_MySWC"> 
</ARObjectReference> 
 
<AttributeDefinitionTableRef  
    Version="1.0"  
    ID="{932D3FD0-2F6C-49BF-80CB-D1C3756D3868}"> 
</AttributeDefinitionTableRef> 
 
    <AttributeValue  
        Name="MySWCEnum"  
        Value="Enum3"> 
    </AttributeValue> 
 
  </ObjectAttributeReference> 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
5  DCF Workspaces 
As DCF workspaces mainly consists of exported AR-XML files the user-defined attributes 
are also used in DCF workspaces. Thus all user-defined attributes can be loaded with the 
attribute  definitions  and  their  corresponding  AR  design  objects  during  opening  a  DCF 
workspace. 
5.1  Global attribute definition file 
Nevertheless, if attribute definitions are defined without usage by a design objects, these 
definitions  will  be  lost  on  opening  the  DCF  workspace.  To  overcome  this  limitation  all 
attribute definitions are stored in a global XML file named like the DCF  workspace name 
with the extension _attr_def.xml 
The  format  is  the  same  as  for  user-defined  attributes  but  the  file  contains  the  attribute 
definitions only. 
5.2  Loading attribute definitions 
On opening a DCF workspace the global attribute definition file is always loaded first. Thus 
all definitions exist and can be referenced by the further AR-XML import. A warning during 
AR-XML import is thrown if the attribute definition within a single _gen_attr.xml differs from 
the globally defined one. In this case the definition from the _gen_attr.xml is ignored and 
only the value of the attribute itself is imported to the design object.  
2012, Vector Informatik GmbH 
Version: 1.3 
 
 


User-defined attribute XML-export Technical Reference 
 
6  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector.com 
 
2012, Vector Informatik GmbH 
Version: 1.3 
 
 

27 - UserManual_DataImport

Microsoft Word - UserManual_DataImport.doc

29 - UserManual_DataImports


 
 
 
 
 
 
 
 
 
 
 
 
Data Import 
User Manual 
 
 
 
 
Version 2.0 
 
 
 
 
 
 
Authors: 
Matthias Wernicke 
Version: 
2.0 
Status: 
released (in preparation/completed/inspected/released) 
 
 
 


User Manual Data Import 
 
1  History 
Author 
Date 
Version 
Remarks 
Wk 
2009-08-27 
1.0  
Initial version 
Document scope extended: description of 
Wk 
2011-01-07 
2.0 
general import mechanisms, description of 
special import functions completed 
 
Contents 
1  History....................................................................................................................... 2 
2  About this Document ............................................................................................... 3 
3  Use Cases ................................................................................................................. 4 
4  Approach .................................................................................................................. 6 
4.1 
Definition of import mode via difference analysis ........................................ 7 
4.2 
Interactive definition of import mode ........................................................... 8 
4.3 
Preset of import mode (automatic merge)................................................... 8 
4.3.1 
Preparation of workspace ........................................................................... 8 
4.3.2 
Automatic pre-setting of import mode for new imported objects.................. 9 
4.3.3 
Resulting behavior of DaVinci Developer.................................................... 9 
5  Special Import Functions......................................................................................... 9 
5.1 
Overwrite Import Mode Preset .................................................................. 10 
5.2 
Update Diagnostic Configuration .............................................................. 11 
6  Contact.................................................................................................................... 12 
 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
2  About this Document 
This  document  describes  the  specific  features  of  DaVinci  Developer  for  importing  data 
according  to  the  AUTOSAR  SWC  Template.  It  is  applicable  for  the  import  of  AUTOSAR 
XML files or DCF files (DaVinci Configuration File).   
For  details  about  the  import  function  for  the  ECU  Configuration  Template,  please  see 
TechnicalReference_EcuConfigurationFiles.pdf. 
Abbreviations and Items used in this Document: 
SWC 
Software Component 
PIM 
Per-Instance Memory 
 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
3  Use Cases 
The specific import/update features of DaVinci Developer are relevant for scenarios, where 
several  involved  persons  (e.g.  the  OEM  and  the  TIER1)  both  contribute  SWC  design 
artifacts to the overall project. 
 
Figure 1 shows an example, where the TIER1 needs to integrate a SWC of the OEM 
 
 
OEM defines an atomic component type with some port prototypes (A). OEM exports 
the component type and passes it to the TIER1 
 
TIER1 imports the component type, and integrates it as component prototype into a 
composition type, which already has some other component prototypes and port 
prototypes (red color in B). 
 
OEM changes the atomic component type, e.g. by adding some port prototypes and 
removing others (C). OEM exports the component type and passes it to the TIER1 
 
TIER1 imports the component type, and expects that the changes of the OEM are 
incorporated (D) 
 
 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
OEM Workspace
TIER1 Workspace
Composition1
SWC1
SWC2
SWC2
A
B
Composition1
SWC1
SWC2
SWC2
C
D
 
Figure 1: Import/Update Example 1 
 
 
 
 
Figure 2 shows an example, where the TIER1 needs to extend a composition of the OEM 
 
 
OEM defines a composition type with some port prototypes and component 
prototypes (A). OEM exports the composition type and passes it to the TIER1 
 
TIER1 imports the composition type, and makes changes like adding further port 
prototypes, component prototypes and connector prototypes (red color in B). TIER1 
considers these changes as “private” and does not return these changes to the OEM. 
 
OEM changes the composition, e.g. by adding some port prototypes and removing 
others (C). OEM exports the composition type and passes it to the TIER1 
 
TIER1 imports the composition type, and expects that the changes of the OEM are 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
incorporated as well as the changes done by the TIER1 (D) 
 
OEM Workspace
TIER1 Workspace
Composition1
Composition1
SWC1
SWC2
SWC2
A
B
Composition1
Composition1
SWC1
SWC2
SWC2
C
D
 
Figure 2: Import/Update Example 2 
 
4  Approach 
The  import  process  in  DaVinci  Developer  considers  individual  objects  within  the  import 
context (set of AUTOSAR XML files or DCF files) and the workspace, see Figure 3. The 
objects are identified by the combination of object type and object short name. Based on 
this identification, the set of objects may be completely disjunctive, or (partially) overlap. 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
Workspace
Import Context
Obj1
Import
Obj2
Obj2
Obj3
Obj3
Obj4
 
Figure 3: Import Context and Workspace 
 
The  import  mode  of  an  object  controls  the  behavior  of  DaVinci  Developer  during  the 
import  process.  The  import  mode  is  expressed  from  the  target  workspace  point  of  view 
with the following options 
 
Keep 
The object in the workspace is not changed 
 
Overwrite 
The object in the workspace is overwritten by the imported object 
 
DaVinci Developer supports the following ways to define the import mode of the objects 
 
Interactively during the import process (user decision not persistent) 
 
Via difference analysis before starting the import process (user decision not 
persistent) 
 
By presetting the import mode (persistent) 
The  user  can  select  the  approach  individually  for  each  import  process  by  checking  the 
according options in the import dialog. 
4.1  Definition of import mode via difference analysis 
Before  running  the  import  process  DaVinci  Developer  opens  a  dialog  showing  the 
differences  between  the  objects  in  the  workspace  and  in  the  import  context.  This 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
difference  dialog  allows  the  user  to  browse  the  differences  and  select  the  import  mode 
(“Keep” or “Overwrite”) for each object. 
4.2  Interactive definition of import mode 
During the import process DaVinci Developer raises dialogs allowing the user to define the 
import  mode.  Such  dialog  is  raised  for  each  individual  object.  For  convenience  reasons, 
these dialogs offer the option to remember the selected import mode for all other objects of 
the same type, or for all remaining objects. 
The interactive definition of import mode offers “Merge object” as import mode. This option 
is relevant for objects, which have sub-objects. It performs an additive merge of the sub-
objects. Instead of the import mode “Keep”, the option “Create new object” is offered. This 
option leaves the existing objects in the workspace unchanged, and creates a new object 
(with different name) instead. 
4.3  Preset of import mode (automatic merge) 
For the following types of objects: 
 
Port prototypes 
 
Component prototypes 
the  import  mode  (“Keep”  or  “Overwrite”)  can  be  preset.  So  this  approach  is  especially 
useful  in  case  the  import  process  will  be  repeated  in  future.  These  settings  become 
effective, if the user chooses “Overwrite” as import mode for a component type. 
4.3.1 
Preparation of workspace 
Before  running  the  import  process  the  user  can  specify  the  import  mode  as  attribute  for 
each  object.  These  attributes  are  persistently  stored  in  the  workspace.  To  enable  this 
approach the workspace must contains the following attribute definitions: 
 
Attribute Definition 
Object Type 
Type 
Range 
IMPORT_MODE_PRESET_PORT 
Port Prototype 
Enumeration 
Keep, Overwrite 
IMPORT_MODE_PRESET_COMPONENT  Component Prototype  Enumeration 
Keep, Overwrite 
 
The recommended default for these attribute definitions is “Keep”. This will ensure that all 
new objects, which are created by the user, will get the import mode “Keep”. 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
These  attribute  definitions are also  contained  in the file  ImportModePreset.arxml,  located 
in the “Data” folder of the DaVinci Developer installation. By importing this file, the attribute 
definitions will be created. 
 
After that, the user can set the attribute values to “Overwrite” for all those objects, which 
should  be  automatically  updated  and  potentially  deleted  during  import.  The  user  can  set 
the  attribute  values  either  manually  (please  refer  to  the  DaVinci  DEV  online  help  for 
details) or using an according special import function (see chapter 5.1). 
4.3.2 
Automatic pre-setting of import mode for new imported objects 
By  an  according  option  in  the  import  dialog,  the  user  may  define  the  value  of  the  import 
mode  preset  attribute  for  all  those  objects,  which  are  created  during  the  import  process 
(i.e. which did not exist in the workspace before the import). It is recommended to set this 
option to “Overwrite”. 
4.3.3 
Resulting behavior of DaVinci Developer 
Assuming that the recommendations mentioned above are fulfilled, DaVinci Developer will 
have the following behavior: 
 
All imported port prototypes and component prototypes have “Overwrite” as import 
mode preset 
 
All port prototypes and component prototypes created by the user have “Keep” as 
import mode preset 
 
The imported port prototypes and component prototypes will be automatically 
updated when the user runs the import again. This includes also deletion of formerly 
imported, now obsolete port prototypes and component prototypes. 
 
Port prototypes and component prototypes created by the user will remain 
unchanged 
This behavior supports the typical use cases (see chapter 3) 
 
5  Special Import Functions 
Besides  the  generic  import  functionality,  DaVinci  Developer  provides  special  import 
functions.  These  special  import  functions  have  a  predefined  behavior  in  terms  of  the 
imported content and in terms of how to react in case of conflicts. 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
5.1  Overwrite Import Mode Preset 
You may use this function to initially prepare a given workspace for the usage of automatic 
merge  based  on  the  import  mode  preset  attributes  (see  chapter  4.2).  This  function  does 
not actually import any data, but it sets the import mode preset attribute for all objects in 
the  workspace,  which  also  exist  in  the  import  context.  The  user  can  define  the  value 
(“Keep”  or  “Overwrite”).  The  function  is  called  via  the  menu  File  |  Special  Import  | 
Overwrite Import Mode Preset. You may select the AUTOSAR XML files to be imported 
via the Import from XML Dialog. Please refer to the DaVinci DEV online help for details 
about this dialog. 
 
Example:  Assuming  an  initial  workspace  as  shown  in  Figure  4,  where  all  objects  have 
attribute  value  “Keep”  (e.g.  because  this  is  the  default  of  the  attribute  definition).  When 
calling this special import function and selecting “Overwrite” as value for the import mode 
preset attribute, the component prototype “SWC2” and all four port prototypes of the import 
context will be tagged as “Overwrite”. All other objects remain at “Keep”. 
 
Workspace (Initial)
Legend:
Composition1
“Overwrite”
SWC1
“Keep”
SWC2
Import Context
Workspace after special import
Composition1
Composition1
SWC1
SWC2
SWC2
 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
Figure 4: Function “Overwrite import mode preset” 
 
 
 
5.2  Update Diagnostic Configuration 
You may use this function to update those parts of the application SWCs in the workspace, 
which  are  related  to  diagnostic  functionality.  The  function  is  called  via  the  menu  File  | 
Special Import | Update Diagnostic Configuration. You may select the AUTOSAR XML 
files  to  be  imported  via  the  Import  from  XML  Dialog.  Please  refer  to  the  DaVinci  DEV 
online help for details about this dialog. 
 
This  function  ensures  that  the  SWCs  in  the  workspace  match  to  the  imported  XML  file, 
while preserving the modifications you made at the SWCs. This is reached by the following 
behavior: 
If the objects in the imported XML file not yet exist in the workspace, they are created by 
the  special  import  function.  If  an  object  already  exists,  the  following  update  approach  is 
performed: 
 
 
Constants are overwritten 
 
Data Types are overwritten 
 
Port Interfaces are overwritten 
  Exception: the Init Value of the Calibration Element Prototypes of Calibration Port 
Interfaces are not changed. 
 
Component Types 
  The Properties of the Component Type are overwritten, except for the 
Implementation Code Type and Supports Multiple Instantiation Flag  
  Port Prototypes 
  Existing  Port  Prototypes  are  overwritten,  except  for  the  Port  API  Options  and 
the Communication Specification 
  Missing Port Prototypes are created 
  Obsolete Diagnostic Port Prototypes* are deleted 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 


User Manual Data Import 
 
  Runnable Entities 
  Existing  Runnable  Entities  are  merged  as  follows:  the  Symbol  and  Can  Be 
Invoked Concurrently is not changed, the Trigger list and Port Access lists are 
merged.  
  Missing Runnable Entities are created 
  Exclusive Areas, Inter-Runnable Variables and Calibration Parameters 
  Existing objects are overwritten 
  Missing objects are added 
  Per-Instance Memory 
  Existing PIMs are overwritten 
  Missing PIMs are added 
  Obsolete Diagnostic PIMs** are deleted 
 
Note: This special import function does not consider the import mode preset attributes (see 
chapter 4.2). 
 
*) Diagnostic Port Prototypes are Port Prototypes, which contain an attribute with a value 
other than the default for an attribute definition, which contains “PDM_ID” in its name 
 
**) Diagnostic PIMs are PIMs, which contain an attribute with a value other than the default 
for an attribute definition, which contains “PDM_ID” in its name 
6  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector-informatik.com 
2011, Vector Informatik GmbH 
Version: 2.0 
 
 

30 - UserManual_Working_with_DCF

UserManual_Working_with_DCF

32 - UserManual_Working_with_DCFs


 
 
 
 
 
 
 
 
 
 
 
 
Working with DCF 
User Manual 
 
 
 
 
Version 1.6 
 
 
 
 
 
 
Authors: 
Matthias Wernicke, Andreas Claus, Stefanie Kruse 
Version: 
1.6 
Status: 
released (in preparation/completed/inspected/released) 
 
 
 


User Manual Working with DCF 
 
1  History 
Author 
Date 
Version 
Remarks 
Wk 
2008-02-07 
0.1  
Initial version 
Wk 
2008-02-08 
0.2 
Additional remark in ch. 5.1 
Ch. 6.2 “Handling of read-only objects” added. 
Wk 
2008-03-27 
1.1 
Ch. 5.1 “Creating a new DCF” updated. Ch. 7 
“Limitations” added. Released. 
Ch. 4 “Relative path handling” added 
Cs 
2008-04-17 
1.2 
Ch. 7 “Limitations” updated 
Ske 
2009-02-08 
1.3 
Ch.7 “DCFUtility” added. “Limitations” removed. 
Wk 
2011-01-10 
1.4 
Harmonized with UserManual_DataImport.pdf  
Wk 
2011-08-12 
1.5 
Ch. 6.2 updated. Screenshots updated. 
Wk 
2012-06-15 
1.6 
Obsolete terms and limitations removed. 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
Contents 
1 
History ....................................................................................................................... 2 
2 
About this Document ............................................................................................... 5 
2.1 
Abbreviations and Items used in this Document ......................................... 5 
3 
Introduction .............................................................................................................. 6 
3.1 
What is a DaVinci Developer Workspace? .................................................. 6 
3.2 
What is a DaVinci Configuration File? ......................................................... 6 
4 
DCF storage format .................................................................................................. 7 
5 
Working with DCF ................................................................................................... 11 
5.1 
Creating a new DCF ................................................................................. 11 
5.2 
Opening an existing DCF .......................................................................... 12 
5.3 
Exporting a DCF ....................................................................................... 13 
5.4 
Importing a DCF ....................................................................................... 14 
5.5 
Converting a DEV into a DCF (or vice versa) ............................................ 14 
6 
Using DCF as interface to a CM system ................................................................ 15 
6.1 
General concept ....................................................................................... 15 
6.2 
Handling of read-only objects ................................................................... 16 
7 
Working with DaVinci Configuration File Utility ................................................... 18 
7.1 
Installation ................................................................................................ 18 
7.1.1 
Setup program .......................................................................................... 18 
7.1.2 
Licensing .................................................................................................. 18 
7.2 
Starting DaVinci Configuration File Utility .................................................. 18 
7.3 
Open DCF workspace .............................................................................. 20 
7.4 
DCF workspace ........................................................................................ 21 
7.4.1 
Content of a DCF workspace .................................................................... 21 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
7.4.2 
Missing files .............................................................................................. 22 
7.5 
DCB files of a DCF workspace ................................................................. 23 
7.5.1 
Content of DCB files ................................................................................. 23 
7.5.2 
Corrupt DCB files ...................................................................................... 23 
7.6 
Compare AUTOSAR files of DCF workspaces .......................................... 25 
7.7 
Command line usage of comparison ......................................................... 26 
8 
Tips and Tricks ....................................................................................................... 27 
8.1 
When to use DEV or DCF? ....................................................................... 27 
8.2 
Working with temporary DEV .................................................................... 27 
9 
Contact .................................................................................................................... 28 
 
Illustrations 
Figure 4-1: Granularity of the design objects in a DCF ........................................................... 8 
Figure 4-2: Folder structure of a DCFP .................................................................................. 8 
Figure 4-3: Example DCF .................................................................................................... 10 
Figure 6-1: Using DCF with a CM system ............................................................................ 16 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
2  About this Document 
Besides the traditional DaVinci Developer Workspace (DEV), DaVinci Developer supports 
an  alternative  storage  format  for  the  design  data:  the  DaVinci  Configuration  File  (DCF). 
This document describes when to use DCFs and how to work with DCFs. 
2.1  Abbreviations and Items used in this Document 
DEV 
DaVinci Developer Workspace 
DCF 
DaVinci Configuration File 
DCFP 
DaVinci Configuration File Package 
DCFE 
DaVinci Configuration File Element 
CM 
Configuration Management 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
3  Introduction 
Design  data  created  with  DaVinci  Devloper  need  to  be  persistently  stored.  You  may 
choose among the following storage formats: 
 
 
DaVinci Developer Workspace (DEV) 
 
DaVinci Configuration File (DCF) 
Both  formats  have  their  specific  advantages.  Depending  on  your  use  cases  you  should 
decide which format is appropriate for you. 
3.1  What is a DaVinci Developer Workspace? 
The  DaVinci  Developer  Workspace  is  the  native  XML  based  storage  format  of  DaVinci 
Developer.  This  storage  format  is optimized  to  achieve  a fast  loading  and  saving  time of 
the design data. 
The detailed storage format is proprietary and might be changed by Vector without notice 
in future DaVinci versions. Of course, loading of old workspaces is always possible with a 
newer DaVinci version. 
3.2  What is a DaVinci Configuration File? 
The DaVinci Configuration File is an alternative storage format of DaVinci Developer. This 
format is appropriate for cooperative working with DaVinci Developer and any external CM 
system  with  a  file-based  interface.  You may  use  DaVinci  Developer  as  authoring  tool for 
the  design  data,  and  you  may  use  the  CM  system  to  manage  the  design  data  in  a 
repository.  This  gives  you  the  maximum  degree  of  freedom  to  use  the  CM  system’s 
features like versioning, branching or merging files. To ensure long term readability of old 
design data in the CM system, the DCF concept avoids proprietary formats where possible 
and uses standardized AUTOSAR XML formats instead. 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
4  DCF storage format 
A  DCF  is  a  storage  format,  which  allows  for  storing  any  AUTOSAR  design  data  and 
related proprietary data as consistent set of files. This overall set of files is called DaVinci 
Configuration File Package (DCFP). A DCFP may consist of the following files: 
 
 
1 DCF (DaVinci Configuration File) 
Central file, which contains file references to a consistent set of ARXML, DCB or 
gen_attr.XML files 
 
1..n DCFE (DaVinci Configuration File Element), each consisting of 
  1 ARXML (AUTOSAR XML file) 
AUTOSAR compliant XML file to store the AUTOSAR design data 
  0..1 DCB (DaVinci Configuration Binary) 
Optional binary file to store the proprietary data (e.g. graphics) of DaVinci, which are 
not covered by AUTOSAR XML formats. The DCB is optional and always 
associated (by file name) to an ARXML. 
  0..1 gen_attr.XML (Generic Attribute XML file) 
Optional XML file in proprietary (but published) format to store the generic attributes 
of the design data. You find the specification of the format in the Technical 
Reference “User-define attribute XML-export”. The gen_attr.XML is optional and 
always associated (by file name) to an ARXML. 
When  using  DCF  in  combination  with  an  external  CM  system,  an  important  topic  is  the 
granularity of the data concerning versioning and branching. A trade-off needs to be found 
between too course grained (hard to merge) and too fine grained (huge number of files). 
DaVinci uses the following granularity within a DCFP: 
 
DaVinci object 
DCFP Granularity 
CAN Bus 
Stored within the DCFE of the ECU Project 
Component Type 
Each Component Type will be stored in as separate DCFE, 
regardless if it’s a Composition or Atomic 
Constant 
All Constants will be stored together in one DCFE  
Data Type 
All Data Types will be stored together in one DCFE  
ECU Project 
Each ECU Project will be stored in a separate DCFE 
FlexRay Cluster 
Stored within the DCFE of the ECU Project 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
LIN Bus 
Stored within the DCFE of the ECU Project 
Port Interface 
All Port Interfaces will be stored together in one DCFE  
Signal 
All Signals will be stored together in one DCFE 
Signal Group 
All Signal Groups will be stored in the Signals-DCFE 
Signal Type 
All Signal Types will be stored in the Signals-DCFE 
Figure 4-1: Granularity of the design objects in a DCF 
In the file system, a DCFP is represented by a folder, which has the following structure: 
 
  <DCFP folder> 
<DCF_name>.dcf 
 
Constants.arxml 
 
Constants_gen_attr.xml 
 
DataTypes.arxml 
 
DataTypes_gen_attr.xml 
PortInterfaces.arxml 
 
PortInterfaces_gen_attr.xml 
 
Signals.arxml 
 
Signals_gen_attr.xml 
ComponentTypes 
 
<Component Type name>.arxml 
 
<Component Type name>.dcb 
 
<Component Type name>_gen_attr.xml 
 
ECUProjects 
<ECU Project name>.arxml 
 
<ECU Project name>.dcb 
 
<ECU Project name>_gen_attr.xml 
 
Figure 4-2: Folder structure of a DCFP 
Storing  a  DCF  into  an  empty  directory  always  creates  the  standard  directory  structure, 
i.e.  Constants,  DataTypes,  PortInterfaces,  and  Signals  are  stored  in  the  DCFP  folder, 
whereas ComponentTypes and ECUProjects get their own subdirectory. 
The paths within the DCF are relative to the DCFP folder. If desired the paths in the DCF 
can  be  modified  using  an  XML-Editor.  This  allows  loading/saving  of  DCF  parts  from 
other directories. 
The paths within the DCF can have a relative path format including any number of parent 
directories or subdirectories or an absolute path format. UNC notation is not supported. 
Example: 
..\..\MyFolder\MySubFolder\Signals.arxml 
 
.\MySignals\Signals.arxml 
 
 E:\DCFPool\MyDCFPart\Signals.arxml 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 



User Manual Working with DCF 
 
Caution 
  The file name itself is fixed and depends on the object type and name of the AUTOSAR 
ARXML file. The additional files (DCB, GEN_ATTR.XML) must always reside in the 
same directory as the ARXML file. It is not allowed to specify different paths within one 
single file reference in the DCF. 
 
Saving a DCF in a directory that already contains the same DCF will keep the paths as 
specified in the existent DCF. In this case the standard directory structure is only applied 
to newly created objects. 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 



User Manual Working with DCF 
 
 
Each file reference requires the definition of the ROOTITEM type that corresponds with 
the  ARXML  file.  During  DCF  loading  this  ROOTITEM  is  evaluated  to  solve  external 
object  references  between  the  various  ARXML  files.  Wrong  or  missing  ROOTITEM 
definitions causes invalid object references that will be reported during DCF loading. 
An example DCF file looks like this: 
 
 
Figure 4-3: Example DCF 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 






User Manual Working with DCF 
 
5  Working with DCF 
5.1  Creating a new DCF 
Select File | New 
workspace… or use the 
shortcut  .  
 
 
 
 
Select “DaVinci Configuration 
Files (*.dcf)” as file type. 
Browse for a suitable folder 
and set a file name for the 
DCF file. 
You may now work as usual in 
with DaVinci Developer to 
define new objects. 
To save the data select 
File | Save Workspace… or 
use the shortcut 

 
 
 
Please observe the following conditions, which apply to the folder of a DCF file: 
 
The folder, which contains the DCF file, must not contain other DCF files 
 
Within the folder of the DCF file and within any sub-folder, the following file types are 
“reserved” for DaVinci 
  *.arxml 
  *.dcf 
  *.dcb 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 





User Manual Working with DCF 
 
  *_gen_attr.xml 
These files are created and deleted by the DaVinci when saving the DCF workspace. 
Other files are not touched by DaVinci. 
 
Sub-folders of the DCF folder are not deleted by DaVinci, even if the sub-folder has 
become obsolete (e.g. since the according object has been deleted in DaVinci) 
5.2  Opening an existing DCF 
Select File | Open… or use the 
shortcut 
  
 
 
 
 
 
 
Select “DaVinci Configuration 
Files (*.dcf)” as file type. 
Browse for the DCF file. 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
5.3  Exporting a DCF 
You may create a new 
DCF as subset of the 
currently opened 
Workspace or DCF. 
Select one or more 
objects in the Library 
Browser and select the 
context menu item 
DCF Export....  
 
 
 
 
 
 
The Export to DCF 
dialog opens. You may 
now select the DCF 
file to create. 
The dialog shows all 
dependent objects of 
the context object(s). 
Near each of these 
objects you see the 
file, which will be used 
to store the object. 
Select Export to 
create the new DCF. 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
 
5.4  Importing a DCF 
You may import a DCF into 
an already opened workspace 
or DCF. 
Select File | Import DCF…  
 
 
 
 
 
5.5  Converting a DEV into a DCF (or vice versa) 
You may convert an 
opened DEV into a 
DCF. 
Select File | Save 
Workspace As….  
 
Select “DaVinci 
 
Configuration File 
(*.dcf)” as file type. 
Browse for a suitable 
folder and set a file 
name for the DCF file. 
 
In a similar way you may convert an opened DCF into a DEV. 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
6  Using DCF as interface to a CM system 
6.1  General concept 
The DCF may serve as interface between DaVinci Developer and your CM system.  
 
 
Using DaVinci Developer you create or edit the DCFP in your working copy of the CM 
repository. 
 
Your working copy may contain several DCFP, e.g. one DCFP per ECU project you 
are currently developing, or some DCFP for particular software components. 
Depending on the capabilities of your CM system you may even have several 
variants (branches) of e.g. the same ECU project as separate DCFP in your working 
copy. 
 
Using the CM system’s user interface you may check-in (commit) the DCFP into the 
repository, or get an already existing DCFP. 
 
The read-only state of files within the DCFP (e.g. because they are checked-in) is 
reflected within DaVinci Developer (see chapter 6.2). 
 
Optionally you may use external utility tools e.g. to merge the ARXML files within a 
DCFP. 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
 
Figure 6-1: Using DCF with a CM system 
6.2  Handling of read-only objects 
After opening a DCF 
workspace, you may display 
the read-only state of the 
objects by selecting  
View | Read-Only State…  
 
 
 
 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
The Read-Only State dialog 
opens. This dialog displays all 
DCFEs of the workspace 
according to the DCFP 
granularity (see chapter 4).  
For each DCFE, the ARXML 
file name is displayed as well 
as the file attribute (“ro” read-
only or “rw” read-write).  
 
If a DCFE is read-only, all 
objects of the DCFE are 
assumed to be read-only. Any 
editing of the objects via 
dialogs or editors is blocked in 
DaVinci Developer. 
If you want to allow editing the 
object anyway, you may select 
the DCFE and push “Set state 
to read/write”. This will make 
the objects in the DCFE read-
 
write, while the files remains 
read-only. Consequently, you 
 
can edit the object, but you 
cannot save the workspace 
unless you make the files “rw”. 
Note: If you have set a DCFE 
to read-write, it is not possible 
to set it to read-only again. 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
7  Working with DaVinci Configuration File Utility 
This section describes working with DaVinci Configuration File Utility. ( DCFUtility ) 
DCFUtility is a tool to handle DCF files. 
 
The functionality of DCFUtility contains: 
 
Visualize all files referenced within a DCF workspace. 
 
Detect missing files of a DCF workspace 
 
Show content of DCB files 
 
Detect corrupt DCB file 
 
Compare AUTOSAR files of two DCF workspaces 
7.1  Installation 
7.1.1 
Setup program 
The DCFUtility can be installed by starting the setup program setup.exe. The tool is 
installed during the installation procedure of DaVinci Developer automatically. 
   
The DCFUtility is installed into the folder of your DaVinci Developer installation. 
The executable “DVDCFUtility.exe” is installed in the sub-folder “bin”. 
7.1.2 
Licensing 
In order to run DCFUtility a license of DaVinci Developer is required on the PC. 
7.2  Starting DaVinci Configuration File Utility 
The DCFUtility can be started via one of the following options  
 
Via the Program menu                                                                                                 
Using Program menu | DaVinci Developer <Version> | DaVinci Configuration File 
Utility the DCFUtility is started. Using File | Open you can open a dialog for selecting 
a DCF file files to be shown. After confirming this dialog, the DCF file is opened 
 
Via the Windows Explorer                                                                                        
After selecting a file with extension .dcf in the Windows Explorer, you can open the 
file using the context menu entry Open with | DaVinci Configuration File Utility  
2012, Vector Informatik GmbH 
Version: 1.6 
 
 



User Manual Working with DCF 
 
 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 





User Manual Working with DCF 
 
7.3  Open DCF workspace 
Select File | Open… or use 
the shortcut 
  
 
 
 
Select “DaVinci 
Configuration Files (*.dcf)” 
as file type. Browse for the 
DCF file. 
 
 
 
 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
7.4  DCF workspace 
7.4.1 
Content of a DCF workspace 
The tree on the left hand shows the 
files referenced within a DCF file. 
The files are sorted within the main 
branches shown in the picture on 
the right side. 
 
 
 
For each DaVinci object there is 
one sub node within the according 
main branch. The sub branches 
name is the name of the DaVinci 
object. The children of the objects 
nodes contain the names of the files 
which belong to one object. 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 






User Manual Working with DCF 
 
7.4.2 
Missing files  
When opening a DCF file 
referenced files in the DCF 
file are checked for 
existence automatically. 
Missing files and their 
parent nodes are marked 
red in the tree view of the 
DCF file. 
Use short cut 
 to start the 
check again manually and 
to update the DCF file’s tree 
view. ( e.g. after copying 
missing files to the location 
specified in the DCF) 
 
 
 
Use short cut 
 to show 
missing files and their 
parents only. 
 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 






User Manual Working with DCF 
 
7.5  DCB files of a DCF workspace 
7.5.1 
Content of DCB files 
Select a DCB file in tree view to 
show its content in the table on 
the right side. 
 
 
 
 
Double click on a row in the 
table to show the object’s 
values.  
 
 
 
 
 
7.5.2 
Corrupt DCB files 
Select  Check  | Corrupt Files 
or use short cut 
 to analyze all 
DCB files for corruptness. 
 
 
 
 
 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 





User Manual Working with DCF 
 
 
Nodes of corrupt DCB files and 
their parent nodes are marked 
red in the DCF file’s tree view.  
 
 
 
 
 
Use short cut 
 to show corrupt 
DCB files only. The short cut is 
enabled after checking the DCF 
file for corrupt DCB files. 
 
 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 






User Manual Working with DCF 
 
7.6  Compare AUTOSAR files of DCF workspaces 
Select File | Compare DCF  
or use short cut   to 
compare all same 
AUTOSAR files which are 
referenced in two DCF files. 
 
 
Select two existing DCF 
files and define a directory 
in which the result files of 
type “dvdiff” may be written. 
Select whether the 
AUTOSAR files are to be 
validated or not. If you 
choose validate “With 
external schema” you have 
to define a XSD file to 
 
validate against. 
 
 
 
In “Comparison Result 
 
Files” dialog a list of result 
files and their result status 
is shown.  
Note: Files at same 
location are not 
compared.  
Result “equal”: No Changes  
Result “different”: Changed 
Result “failed”: Comparison 
 
failed. The results are 
written into an error file. 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 




User Manual Working with DCF 
 
Double click a table row of 
the “Comparison Result 
Files” dialog to show the 
result file of the comparison 
in “AUTOSAR XML 
DifferenceView”.  
 
 
 
or the error file of a failed 
comparison. 
 
 
 
 
 
7.7  Command line usage of comparison 
You can run the DCFUtility comparison of DCF files by the following command: 
DVDCFUtility.exe –s <dcffile1> -c <dcffile2> -o <resultdir> 
 
 
 parameters 
  –s <dcffile1> source file. 
  –c <dcffile2> DCF file which is compared with the source file. 
–o <resultdir> path of result directory which contains the difference files of all 
AUTOSAR files contained in both <dcffile1> and <dcffile2> 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
8  Tips and Tricks 
8.1  When to use DEV or DCF? 
You  should  use  the  DaVinci  Developer  Workspace  in  case  you  need  a  fast,  local 
saving/loading of your design data. 
 
You  should  use  the  DaVinci  Configuration  File  in  case  you  want  to  manage  the  design 
data as AUTOSAR compliant files in an external CM system.  
8.2  Working with temporary DEV 
Saving and loading of a DCF usually takes more time than saving and loading of a DEV of 
the same content. If you e.g. work for several days on your design data without having to 
check-in/commit your work into the CM system, it may be useful to work like this: 
 
 
Get the DCF from the CM system into your local working copy (e.g. 
c:\work\mySystem.dcf) 
 
Save the DCF as temporary DEV (e.g. c:\tmp\mySystem.DEV) 
 
Work on the temporary DEV 
 
Save the temporary DEV back into the DCF in the working copy (e.g. 
c:\work\mySystem.dcf)  
2012, Vector Informatik GmbH 
Version: 1.6 
 
 


User Manual Working with DCF 
 
9  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector.com 
 
2012, Vector Informatik GmbH 
Version: 1.6 
 
 

33 - Welcome

Welcome to the Java(TM) Platform

Welcome to the JavaTM Platform

Welcome to the JavaTM Standard Edition Runtime Environment. This provides complete runtime support for Java applications.

The runtime environment includes the JavaTM Plug-in product which supports the Java environment inside web browsers.

References

See the Java Plug-in product documentation for more information on using the Java Plug-in product.

See the Java Platform web site for more information on the Java Platform.


Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.

34 -

DaVinci Developer Release Notes

DaVinci Developer 3.11 Installation Guide

Copyright (c) 2000-2015 by Vector Informatik GmbH


Installation of DaVinci Developer

Compatibility

A correct configuration of the MICROSAR RTE is only possible if you use the dedicated version of the DaVinci Developer. Please check the MICROSAR Rte Compatibility Matrix to find the DaVinci Developer version you need.

Please Note: Your licensed DaVinci Developer version defines the highest version you are able to use. Depending on the specific basic software version of a project you might need to use a tool version which is lower than your actual licence.

External Components

In order to work with DaVinci Developer some shared external components have to be installed first. Please install the latest DaVinci External Components Setup from the Vector Download Center

Setup Program

Start the DaVinci setup program Setup.exe and follow the setup steps.

Please note: You must have administrator rights to install DaVinci Developer.

Under some circumstances the InstallShield setup can't be started on a network drive. To ensure proper installation please copy the full installation setup into a temporary directory on a local drive and execute the Setup.exe from this directory.


System modifications performed by DaVinci Developer setup

Shared components

DaVinci External Components Setup will install the following shared runtime components:

  • Microsoft Visual C++ Runtime
  • Microsoft .NET Framework 2.0 SP2
  • Microsoft MSXML Parser
  • Vector License Manager
  • Vector CANdela Converter Add-On
  • Vector DaVinci Difference Analyzer
  • Vector DaVinci Project Assistant
  • Vector AUTOSAR Explorer
  • Vector AUTOSAR Scripting Engine
  • Vector Eparm (DaVinci Configurator Pro .MD)
  • Vector DaVinci 64 Bit Support
  • Vector DaVinci Floating License Manager
  • Vector vVIRTUALtarget basic

Please visit the Vector Download Area for a complete list with specific versions.

Shared DaVinci components are installed in the Windows <COMMONFILES>\Vector\DaVinci directory (e.g. "C:\Program Files (x86)\Common Files\Vector\DaVinci).

The DaVinci Difference Analyzer is installed in <COMMONFILES>\Vector\DaVinci\DiffAnalyzer containing the command-line difference tool and the viewer.

The DaVinci Project Assistant is installed in <COMMONFILES>\Vector\DaVinci\ProjectAssistant.

The Vector AUTOSAR Explorer is installed in <PROGAMFILES>\Vector AUTOSAR Explorer.

NOTE: The Vector AUTOSAR Explorer requires that Microsoft .NET Framework 4 is installed on the PC. Please visit the Microsoft Website for .NET 4 download.

Program files

The DaVinci setup program installs the DaVinci root folder (e.g. "C:\ProgramFiles (x86)\Vector DaVinci Developer 3.11") with the following sub folders

  • Bin: Program files, libraries and the DaVinci-DTD files
  • Data: Example workspace
  • Docs: Documentation
  • Reporting: Report generator
  • Output: Standard output directory for generated files
  • Work: Standard working directory

Start menu

The DaVinci setup program adds a menu entry "Vector DaVinci Developer 3.11" to your Windows start menu with the following links

  • DaVinci Developer
  • DaVinci Documentation Browser
  • DaVinci Installation Manager
  • DaVinci Difference Viewer
  • DaVinci Configuration File Utility

Desktop

The DaVinci setup program adds a link to the DaVinci Developer to the desktop.


Product activation

To activate the DaVinci FlexNet license on your PC you may use the Vector License Manager installed by the DaVinci External Components Setup

Details can be found in the document LicenseManagerHelp.pdf in C:\Program Files (x86)\Vector License Manager\Docs.


Deinstallation

Deinstallation of DaVinci Developer

Open the Windows standard dialog of installed software (Start menu | Settings | System control | Software)

Select "Vector DaVinci Developer" and push "Modify/Remove"

Choose "Remove" in the DaVinci Developer Setup dialog and the setup steps to remove DaVinci

Deinstallation of shared components

Additionally you may deinstall the shared components if they are no longer used by other DaVinci applications (e.g. DaVinci Configurator Pro)


Parallel installation

You may subsequently install several different versions of the DaVinci Developer on the same PC. You may choose the same root folder, if the installations are compatible. The setup program checks this compatibility. In case of incompatible installations you have to select a different root folder.

Only one of the installations can be active. To change the active installation you must use the DaVinci Installation Manager.

You find the DaVinci Installation Manager (DVInstMgr.exe) in the "Bin" sub-folder of the DaVinci root folder. The DaVinci Installation Manager displays a list of all DaVinci installations on the PC. The active installation is displayed bold with an additional DaVinci icon. To activate a different installation you may select it in the list and push the "Activate" button.

35 -

DaVinci Developer Release Notes

DaVinci Developer Release Notes

Copyright (c) 2000-2015 by Vector Informatik GmbH


Table of contents

DaVinci Developer Version 3.11 (SP1)
DaVinci Developer Version 3.11
DaVinci Developer Version 3.10 (SP3)
DaVinci Developer Version 3.10 (SP2)
DaVinci Developer Version 3.10 (SP1)
DaVinci Developer Version 3.10
DaVinci Developer Version 3.9 (SP3)
DaVinci Developer Version 3.9 (SP2)
DaVinci Developer Version 3.9 (SP1)
DaVinci Developer Version 3.9
DaVinci Developer Version 3.8 (SP4)
DaVinci Developer Version 3.8 (SP3)
DaVinci Developer Version 3.8 (SP2)
DaVinci Developer Version 3.8 (SP1)
DaVinci Developer Version 3.8
DaVinci Developer Version 3.7 (SP6)
DaVinci Developer Version 3.7 (SP5)
DaVinci Developer Version 3.7 (SP4)
DaVinci Developer Version 3.7 (SP3)
DaVinci Developer Version 3.7 (SP2)
DaVinci Developer Version 3.7 (SP1)
DaVinci Developer Version 3.7
DaVinci Developer Version 3.6 (SP4)
DaVinci Developer Version 3.6 (SP3)
DaVinci Developer Version 3.6 (SP2)
DaVinci Developer Version 3.6 (SP1)
DaVinci Developer Version 3.6
DaVinci Developer Version 3.5 (SP4)
DaVinci Developer Version 3.5 (SP3)
DaVinci Developer Version 3.5 (SP2)
DaVinci Developer Version 3.5 (SP1)
DaVinci Developer Version 3.5
DaVinci Developer Version 3.4
DaVinci Developer Version 3.3 (SP5)
DaVinci Developer Version 3.3 (SP4)
DaVinci Developer Version 3.3 (SP3)
DaVinci Developer Version 3.3 (SP2)
DaVinci Developer Version 3.3 (SP1)
DaVinci Developer Version 3.3
DaVinci Developer Version 3.2 (SP7)
DaVinci Developer Version 3.2 (SP6)
DaVinci Developer Version 3.2 (SP5)
DaVinci Developer Version 3.2 (SP4)
DaVinci Developer Version 3.2 (SP3)
DaVinci Developer Version 3.2 (SP2)
DaVinci Developer Version 3.2 (SP1)
DaVinci Developer Version 3.2
DaVinci Developer Version 3.1 (SP4)
DaVinci Developer Version 3.1 (SP3)
DaVinci Developer Version 3.1 (SP2)
DaVinci Developer Version 3.1 (SP1)
DaVinci Developer Version 3.1
DaVinci Developer Version 3.0 (SP5)
DaVinci Developer Version 3.0 (SP4)
DaVinci Developer Version 3.0 (SP3)
DaVinci Developer Version 3.0 (SP2)
DaVinci Developer Version 3.0 (SP1)
DaVinci Developer Version 3.0
DaVinci Tool Suite Version 2.3 (SP7)
DaVinci Tool Suite Version 2.3 (SP6)
DaVinci Tool Suite Version 2.3 (SP5)
DaVinci Tool Suite Version 2.3 (SP4)
DaVinci Tool Suite Version 2.3 (SP3)
DaVinci Tool Suite Version 2.3 (SP2)
DaVinci Tool Suite Version 2.3 (SP1)
DaVinci Tool Suite Version 2.3
DaVinci Tool Suite Version 2.2 (SP4)
DaVinci Tool Suite Version 2.2 (SP3)
DaVinci Tool Suite Version 2.2 (SP2)
DaVinci Tool Suite Version 2.2 (SP1)
DaVinci Tool Suite Version 2.2
DaVinci Tool Suite Version 2.1 PRE (SP3)
DaVinci Tool Suite Version 2.1 PRE (SP2)
DaVinci Tool Suite Version 2.1 PRE (SP1)
DaVinci Tool Suite Version 2.1 PRE
DaVinci Tool Suite Version 2.0 PRE (SP3)
DaVinci Tool Suite Version 2.0 PRE (SP2)
DaVinci Tool Suite Version 2.0 PRE (SP1)
DaVinci Tool Suite Version 2.0 PRE
DaVinci Tool Suite Version 1.0 (SP4)
DaVinci Tool Suite Version 1.0 (SP3)
DaVinci Tool Suite Version 1.0 (SP2)
DaVinci Tool Suite Version 1.0 (SP1)
DaVinci Tool Suite Version 1.0
DaVinci Tool Suite Version 0.9.8
DaVinci Tool Suite Version 0.9.7 (SP1)
DaVinci Tool Suite Version 0.9.7
DaVinci Tool Suite Version 0.9.6
Additional Information

DaVinci Developer Version 3.11 (SP1)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • The official 'ServiceProvider' attribute is now supported to annotate the BSW Module origin
  • The pointer datatype DATA_REFERENCE is now fully supported
  • End-to-End protections without port references but with signal group references are now supported
  • 'Create Port Prototypes' functionality now supports the signal group degradation use case

Usability enhancements

  • Invalid generic attribute definition files are now displayed in the Action-Log during workspace loading
  • Additional check has been added to ensure that the compu-methods category of an implementation data-type is either BITFIELD_TEXTTABLE or TEXTTABLE
  • Additionally merged usability enhancements from service packs of previous releases:
    • The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
    • Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
    • Menu command to reset the toolbar and docking window layout has been added
    • Find results view now displays the parent element in a separate column
    • Multi-select and default settings usability enhancements for End-to-End Protection configuration
    • The available filter options from the import dialog are now available via command line DVImEx
    • Structure graphics is now changeable even if the composition type is locked
    • Multi-select editing of Communication Specification values is now supported
    • A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
    • Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
    • Enhancements in consistency checks for NV components
    • Import dialog now contains a simplified file/folder selection button
    • Additional consistency check to avoid data types referencing a data type with the same name

Fixed issues

  • The data-type-mapping-refs were cleared during update of the diagnostics data using the special import mode
  • When creating a server runnable from a nv-component the name of the server-runnable was created with the pattern 'port-prototype'_'operation_name' which could lead into name clashes
  • DaVinci DEV crashed without any error message if the direction of a port prototype was changed while a runnable data access existed
  • Additionally merged issues from service packs of previous releases:
    • Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
    • Modifications in the recent import file list caused a workspace modification
    • ARXML import merge aborted when trying to merge an union data type.
    • Import with function 'check for differences' aborted if a new element had to be created but its package already exists
    • After creating a port from a signal using the 'Create Port Prototypes' function the port was not compatible to the signal if a physical constraint was specified
    • Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
    • Additionally merged issues from service packs of previous releases:
    • AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
    • AUTOSAR 4 import of a negative exponential value ignored the sign
    • Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
    • Creating an OnTransitionTrigger from the runnable context menu didn't work
    • Not all Asian characters could be used in description fields
    • Find unused object menu was sometimes disabled
    • Create Port-Prototypes function didn't create record data-types for signal groups
    • Developer crashed when importing an enumeration data type with physical and internal constraints
    • AUTOSAR 4: Signal-Port time out value was not imported
    • AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
    • An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
    • Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
    • Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
    • The name of an imported argument prototype wasn't imported correctly
    • End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
    • Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
    • Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
    • Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
    • NV component couldn't be configured in the local composition view
    • Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
    • Blueprints couldnt be exported to DCF
    • Crash fixed if context component for create port prototypes was selected as "none"
    • AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
    • AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
    • The data type reference of a calibration element prototype wasn't set after import
    • Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
    • Copying a runnable broke the data model and causes undesired wait points
    • Duplicating an Object copied the original UUID instead of creating a new one.
    • HTML links in descriptions didn't appear in the report
    • Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group

(top)


DaVinci Developer Version 3.11

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • COM-based Transformer can now be configured; supporting End-to-End Protection profiles 1+2
  • Enhancements of NV Block SWC:
    • supporting now also Client/Server- and ModeSwitch-interfaces
    • explicit modelling of different writing strategies
    • multiple NvBlock to port mappings for dual-sided RAM block access

Usability enhancements

  • Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
  • Enhanced tool interaction allows to create Service-Ports directly from within DaVinci Configurator Pro

Fixed issues

  • In rare cases the library tree contained obsolete items due to a missing update
  • UUIDs of SwcServiceDependencies and NvBlockDescriptors were missing in the ARXML export
  • Tool crashed when a locked component type was assigned to the DataTypeMappingSet in the Data-Type-Mapping-Set dialog
  • If the workspace was part of a DPA project a XML parser error code 0x800C0006 was shown when opening a DCF workspace from Windows Explorer with a double click

(top)


DaVinci Developer Version 3.10 (SP3)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • End-to-End protections without port references but with signal group references are now supported
  • 'Create Port Prototypes' functionality now supports the signal group degradation use case

Usability enhancements

  • The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
  • Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
  • Menu command to reset the toolbar and docking window layout has been added
  • Find results view now displays the parent element in a separate column
  • Multi-select and default settings usability enhancements for End-to-End Protection configuration
  • The available filter options from the import dialog are now available via command line DVImEx
  • Structure graphics is now changeable even if the composition type is locked
  • Multi-select editing of Communication Specification values is now supported
  • A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
  • Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
  • Enhancements in consistency checks for NV components
  • Import dialog now contains a simplified file/folder selection button
  • Additional consistency check to avoid data types referencing a data type with the same name

Fixed issues

  • Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
  • Modifications in the recent import file list caused a workspace modification
  • ARXML import merge aborted when trying to merge an union data type.
  • Import with function 'check for differences' aborted if a new element had to be created but its package already exists
  • After creating a port from a signal using the 'Create Port Prototypes' function the port was not compatible to the signal if a physical constraint was specified
  • Additionally merged issues from service packs of previous releases:
    • Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
    • Additionally merged issues from service packs of previous releases:
    • AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
    • AUTOSAR 4 import of a negative exponential value ignored the sign
    • Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
    • Creating an OnTransitionTrigger from the runnable context menu didn't work
    • Not all Asian characters could be used in description fields
    • Find unused object menu was sometimes disabled
    • Create Port-Prototypes function didn't create record data-types for signal groups
    • Developer crashed when importing an enumeration data type with physical and internal constraints
    • AUTOSAR 4: Signal-Port time out value was not imported
    • AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
    • An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
    • Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
    • Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
    • The name of an imported argument prototype wasn't imported correctly
    • End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
    • Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
    • Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
    • Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
    • NV component couldn't be configured in the local composition view
    • Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
    • Blueprints couldnt be exported to DCF
    • Crash fixed if context component for create port prototypes was selected as "none"
    • AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
    • AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
    • The data type reference of a calibration element prototype wasn't set after import
    • Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
    • Copying a runnable broke the data model and causes undesired wait points
    • Duplicating an Object copied the original UUID instead of creating a new one.
    • HTML links in descriptions didn't appear in the report
    • Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group

(top)


DaVinci Developer Version 3.10 (SP2)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Various roundups and extensions have been implemented for the Diff/Merge functionality, especially support for NV-Data-Interfaces and Packages
  • Function "Create Port Prototypes" can now be used on signals that don't have a base type

Usability enhancements

  • ARXML import dialog can now load an external .txt file that contains a list of the file name references to be imported. Paths can be absolute, relative (to the .txt itself) and just the filename itself (same directory).
  • Saving a DCF workspace can now remove files for deleted objects. This option can be activated in the workspace settings.

Fixed issues

  • If falsely an invalid Invoke Operations Port-Access was defined on a non-Client port, the DCF workspace couldn't be loaded anymore
  • A project wasn't updated correctly if the elements were part of a package named "Autosar_Platform".
  • Exporting a Mode Declaration Group contained the category. This category is now corrected to the ALPHABETICAL_ORDER or EXPLICIT_ORDER.
  • In some cases the diff/merge crashed when importing communication data with "check for differences" option.
  • Importing an new ECU SW-Composition delegation port in a previous workspace with "check for differences" option enabled, the data mapping of this port wasn't created.
  • Error 40391 "Invalid integer for criterion" was reported if the project contained more than 4 variants
  • For some object types the package icon was missing in the Library Browser's type view
  • Item is read-only error occurs when opening a SWC composition that contained a read-only atomic SWCs with an outdated interface graphic.
  • The references to a Mapping Set from a NvBlockComponent were not persistent
  • Automatic data type mapping falsely created a fix-size implementation array for a dynamic-size application array
  • Function "Create Server Runnables" created duplicate runnables and allowed invalid prefix / postfix strings

(top)


DaVinci Developer Version 3.10 (SP1)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Vector FlexNet Pool License model is now supported
  • Support for signals which are transmitted over container PDUs has been added

Fixed issues

  • Exception was raised when adding a file to the ARXML import list if a J1939 cluster contained a NODE-NAME and the ECU-INSTANCE attribute
  • DVImEx command line tool falsely showed the message "Referenced DPA file from the DCF workspace differs to the load DPA file" if a relative path was given
  • TP Signals weren't displayed with the correct frame in the Data-Mapping view for the 1:N use case
  • Some smaller GUI roundups and fixes have been made when using union data types

(top)


DaVinci Developer Version 3.10

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Mapping of Data-Prototypes in different Port-Interfaces is now supported
  • Text table mapping for Bit fields is now available
  • Background event trigger can now be defined at the runnable
  • End-to-End protection profiles 5 and 6 are now supported
  • UTF-16 base type encoding can now be specified
  • UNION data types are now supported

Usability enhancements

  • More detailed log messages during ARXML import if generic attributes reference obsolete objects
  • Additional checks to detect more NvM Service Need inconsistencies
  • AUTOSAR Platform types are now defined in a separate ARXML file and automatically used for new projects
  • The path to the .dpa project file is now stored in the .dcf file to allow manual adaptation

Fixed issues

  • ARXML import throws an error if the same Client/Server interface was defined in multiple files which were imported in the same step
  • Consistency check reports incompatible data types if the Type-Emitter where different
  • Communication information was accidently removed when importing a SYSTEM with software design but without communication

(top)


DaVinci Developer Version 3.9 (SP3)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Fixed issues

  • Standard Nvm interfaces were missing on creating a new AR 4.1.3 workspace
  • Migration of a DCF workspace to a different AUTOSAR schema version wasn't possible because the SaveAs menu entry was disabled
  • Record Constant dialog couldn't be opened for the port prototype if a Com-Spec wasn't defined at the data element of the port
  • Create Port Prototypes function created an invalid init value for complex data types
  • ARXML import threw a fatal error if the same client-server interface was specified in different files and the files were imported at the same time
  • The automatic Application to Implementation Data-Type Mapping falsely created a fix-size Impl-array for a dynamic-size Appl-array and reported this as invalid mapping
  • Not all Asian characters could be used in description fields

(top)


DaVinci Developer Version 3.9 (SP2)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Compatibility checks for Bit fields have been improved

Usability enhancements

  • Output of check message 40224: "Unused data element prototype" can now be omitted by the option "Report unused Data Elements" in the workspace setting dialog
  • Command line tool DVImEx now supports the "SubstituteMissingObjects" option
  • For iterative import/export workflow purposes an additional import option "Keep existing UUIDs" is now available
  • Additional function "Adopt structure..." to align the value definition structure to the structure of the actual data type
  • In selection dialogs the init values are now filtered according to the data type

Fixed issues

  • Referenced mode declaration groups were missing in DCF export when data type mapping sets where used
  • In rare cases the relative DPA project file path couldn't be found if the current directory had been changed via the open file dialog
  • End-to-End protection consistency check didn't worked within compositions
  • Port access settings of runnables were invalid after they were copied in the runnable list
  • Frame assignment was not visible for Signal-PDUs which were connected to a NPDU via the TP-Connection
  • Multiple recursive usage of constant references leaded to an exception
  • Data mapping for Signal-Groups didn't worked if Sub-Elements were incompatible
  • Cancel button for "InitValue" of Record- and Array data types had no effect

(top)


DaVinci Developer Version 3.9 (SP1)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • AUTOSAR schema 4.2.1 is now supported
  • Memory Section assignment is now available for NvBlockDescriptor:RAMBlock
  • PR-Ports can now be used for Mode-Ports and NvData-Ports
  • Bit field data types are now supported by using the BITFIELD_TEXTTABLE in the compu-method

Usability enhancements

  • Workspace interaction with DaVinci Configurator has been enhanced by using a lock file mechanism during workspace save
  • Creation of a Data-Mapping for a variant signal now evaluates the variant information to set the same variant condition

Fixed issues

  • Data element properties couldn't be opened from within the Data Mapping signal view
  • Interfaces View in software component editor was falsely disabled for NvComponents
  • Most recently used workspace list showed the location of the temporary workspace after a project update using DaVinci Configurator
  • Frame was not imported if a frame triggering specifies RX-IDENTIFIER-RANGE instead of IDENTIFIER
  • DCF workspace couldn't be loaded if the port direction was changed without performing a consistency check which will correct the port connector
  • Error message 'Current special import can only import System Template files' was thrown when using special import feature
  • Tool tip didn't work when hovering over a array constant with many values
  • LIN-PDUs without frame triggerings couldn't be imported
  • Consistency checks for NV-Component init values have been corrected
  • DCF workspace contained elements with the same UUID if the component type was duplicated by the copy function in the Library-View
  • It was falsely possible to update the project in DaVinci Configurator when the workspace was opened in DaVinci Developer
  • PR-Port generation didn't work in case of a complex data type

(top)


DaVinci Developer Version 3.9

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Post-Build selectable use-case is now supported by using AUTOSAR Variant Handling for data-mapping with variation points at the communication
  • General support of PDUs without frames has been implemented for all cluster types
  • Communication data has been restructured so that DaVinci Developer can directly work on DaVinci Configurator's communication files
  • COM signals with shared ISignalToIPDUMapping are now supported
  • uint64 and sint64 are now supported as platform types
  • Server argument implementation policy attribute is now supported in the operation prototype dialog
  • Port access mode 'ReceivePointByValue' is now supported
  • End-to-End protection now supports profile 4 for Client/Server inter-ECU communication
  • Optional definition of service need parameters

Usability enhancements

  • Additional 'Check Workspace' button is now available in the toolbar
  • Project update has been simplified to update the DaVinci Developer workspace without user interaction

Fixed issues

  • 'Complete Ports' functionality produced wrong opposite ports if a context component type was used
  • 'Save As...' functionality has been disabled for projects with DaVinci Configurator Pro because it corrupted the external file references
  • HTML links in the description field were not correctly displayed in the report
  • The Diagnostics Event Need value 'ConsiderPTO Status' was not correctly set by ARXML import
  • Project update with DaVinci Configurator Pro command line tool ended with error -1060110332 (0xC0D00004)
  • Port Defined Argument Value could falsely be defined on non-server ports
  • Consistency check of the Rte generator falsely reports consistency errors when started within DaVinci Developer
  • Consistency check of service needs caused memory leaks

(top)


DaVinci Developer Version 3.8 (SP4)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • End-to-End protections without port references but with signal group references are now supported
  • The 'Create PortPrototype from Signal' functionality now supports the signal group degradation use case

Usability enhancements

  • The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
  • Additionally merged enhancements from service packs of previous releases:
    • Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
    • Menu command to reset the toolbar and docking window layout has been added
    • Find results view now displays the parent element in a separate column
    • Multi-select and default settings usability enhancements for End-to-End Protection configuration
    • The available filter options from the import dialog are now available via command line DVImEx
    • Structure graphics is now changeable even if the composition type is locked
    • Multi-select editing of Communication Specification values is now supported
    • A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
    • Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
    • Enhancements in consistency checks for NV components
    • Import dialog now contains a simplified file/folder selection button
    • Additional consistency check to avoid data types referencing a data type with the same name

Fixed issues

  • Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
  • Additionally merged issues from service packs of previous releases:
    • AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
    • AUTOSAR 4 import of a negative exponential value ignored the sign
    • Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
    • Creating an OnTransitionTrigger from the runnable context menu didn't work
    • Not all Asian characters could be used in description fields
    • Find unused object menu was sometimes disabled
    • Create Port-Prototypes function didn't create record data-types for signal groups
    • Developer crashed when importing an enumeration data type with physical and internal constraints
    • AUTOSAR 4: Signal-Port time out value was not imported
    • AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
    • An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
    • Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
    • Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
    • The name of an imported argument prototype wasn't imported correctly
    • End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
    • Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
    • Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
    • Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
    • NV component couldn't be configured in the local composition view
    • Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
    • Blueprints couldnt be exported to DCF
    • Crash fixed if context component for create port prototypes was selected as "none"
    • AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
    • AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
    • The data type reference of a calibration element prototype wasn't set after import
    • Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
    • Copying a runnable broke the data model and causes undesired wait points
    • Duplicating an Object copied the original UUID instead of creating a new one.
    • HTML links in descriptions didn't appear in the report
    • Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group

(top)


DaVinci Developer Version 3.8 (SP3)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Usability enhancements

  • Missing compu-method category in ARXML file is now added by the import with a reasonable value
  • Additional option in SaveAs... to migrate the version of an existing DCF workspace in-place without changing the project structure
  • External service components change detection doesn't show the import dialog any more
  • Check for multiple signal group mappings is now enhanced enhancement for PR-Ports
  • Multiple selection of objects in several packages is now supported in the Library-View package tab

Fixed issues

  • The data reception trigger couldn't be created for a NV-DataElement
  • DCF workspace couldn't be loaded if data accesses exist without data element prototype
  • Setting to deactivate End-to-End protection consistency checks was loaded always enabled
  • Newly created data type/constant was added to the default package instead of the selected package
  • Auto connect created redundant connections for PR-ports if they were already connected
  • Obsolete data mappings were displayed in the signal mode of the data mapping view when the data transformation was enabled

(top)


DaVinci Developer Version 3.8 (SP2)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Usability enhancements

  • An additional "Check Workspace" button is now available to check the full workspace independent from the selected element
  • The layout and content of NV Block Component Types has been adapted to match the NvM Block Needs page of regular SWC types

Fixed issues

  • AUTOSAR 3 workspaces could still be created which is no longer supported in this release
  • References to compu method and data constraints were missing if Signals are defined prior to the referenced elements in the ARXML file
  • An empty NUMERIC-VALUE-SPECIFICATION was exported if a communication specification hadn't defined any init value
  • In rare cases DCF workspace couldn't be saved due to duplicate short names
  • AUTOSAR 3 cross-import didn't understand hex string values like "A0:A1:A2"
  • The Rte generation added ComGroupSignals to the ECU-C configuration although they are not related to the ComSignalGroup
  • Memory leaks occurred during consistency check of service needs
  • Wrong focus selection handling in service needs edit files has been corrected

(top)


DaVinci Developer Version 3.8 (SP1)

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Export to AUTOSAR schema version 4.1.1 is now supported
  • Application-Ports are now supported at Service Components

Fixed issues

  • Keyboard-navigation through editors(Ctrl+HOME/Ctrl+END) didn't work anymore
  • Invalid NvM ServiceNeeds configuration wasn't exported to ARXML
  • Import of component type was canceled if a port defined argument value existed and its value didn't define a short label.
  • ARXML import crashed when importing an inconsistent array data type
  • AUTOSAR 3 cross-import didn't import the system signals into the specified package
  • "Parameter is incorrect" exception was threw during copying a data element
  • Data exchange analysis showed no communication if an incompatible connector existed in the software design
  • "Adapt Connected Port Prototypes" functionality failed when using PR-Ports
  • Port assignments at the service needs got lost when opening a DaVinci DEV 3.6 workspace
  • ARXML import update use-case didn't work with init-triggers in 4.1.2 format
  • PR-Ports aren't shown as compatible in the Connector Dialog

(top)


DaVinci Developer Version 3.8

NOTE

This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.

Tool features

  • Combined provide-require-ports (PRPortPrototype) can be defined in the software design
  • Explicit modelling of E_OK as application error is now possible
  • Service Needs have been extended for NvM Top-Down service configuration
  • OBD Ratio Service Need has been added
  • Introducing Sender/Receiver Serialization via Transformer concept (AR4.2.1 preview-feature)
    • Data transformation currently only supported for SOME/IP serialization
    • Inter-Ecu Client/Server Communication is available for signals using data transformation
    • Specific End-to-End protection profiles for data transformation have been added
    • End-to-End protection is now supporting also primitive data elements

Usability enhancements

  • Init-Runnables are described with the standardized AUTOSAR InitEvent
  • TypeReferences now support Data-Constraints
  • Data Exchange Analysis now displays the effective Init-Value

(top)


DaVinci Developer Version 3.7 (SP6)

Tool features

  • End-to-End protections without port references but with signal group references are now supported
  • 'Create PortPrototypes' functionality now supports the signal group degradation use case

Usability enhancements

  • Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
  • Menu command to reset the toolbar and docking window layout has been added
  • Find results view now displays the parent element in a separate column

Fixed issues

  • AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
  • AUTOSAR 4 import of a negative exponential value ignored the sign
  • Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
  • Creating an OnTransitionTrigger from the runnable context menu didn't work

(top)


DaVinci Developer Version 3.7 (SP5)

Usability enhancements

  • Multi-select and default settings usability enhancements for End-to-End Protection configuration
  • The available filter options from the Import dialog are now available via command line DVImEx
  • Structure graphics is now changeable even if the composition type is locked
  • Multi-select editing of Communication Specification values is now supported
  • A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema

Fixed issues

  • Not all Asian characters could be used in description fields
  • Find unused object menu was sometimes disabled
  • Create Port-Prototypes function didn't create record data-types for signal groups
  • Developer crashed when importing an enumeration data type with physical and internal constraints
  • AUTOSAR 4: Signal-Port time out value was not imported
  • AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
  • An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
  • Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
  • Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
  • The name of an imported argument prototype wasn't imported correctly
  • End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
  • Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
  • Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step

(top)


DaVinci Developer Version 3.7 (SP4)

Tool features

  • Export of ARXML files with AUTOSAR schema 4.1.1 is now supported
  • Support of signals sent on several frames on several channels of a cluster has been added
  • Text-ValueSpecification can now be used as init value for an Enum Data-Type
  • AUTOSAR 3: Service Mapping for S/R Ports supports now n:1 connections

Usability enhancements

  • Automatic data-mapping can now be disabled while creating port-prototypes
  • Select-All in Library view no works as a 'deep select' on all subjacent items
  • 'Flip Direction' command is now available at port prototypes in the Component Editor
  • After Copy&Paste of port prototypes to the port list, the new ports are now selected automatically

Fixed issues

  • ECU-C synchronization added unnecessary COM-Callbacks if the same OS application was used by multiple tasks
  • Illegal file split was created during project update if signals have been moved into a signal group of a different package
  • End-to-End Protection profiles _XOR and _XOR+2 didn't allow a DataID of 0
  • DVImEx command line tool didn't export all referenced elements
  • Record element literals were not unique after adapting record constants to a modified structure
  • The DCF save of a software component was incomplete if obsolete Port-Accesses existed
  • Crash during ARXML import fixed if AUTOSAR 3 objects are imported in a new, empty DEV workspace with the ''Substitute missing Objects' flag enabled.
  • Import/export of the SYSTEM element didn't preserve the original system name
  • Unconnected data mappings of TX/RX signal with two different data elements were not persistent in AUTOSAR 3 DCF workspaces
  • Signals with an invalid-value and an init-value lead to a duplicate short-name in AUTOSAR 4
  • Signals were missing after AUTOSAR 4 import if the ECU-Extract contained one or more Ethernet clusters.
  • Calibration-Support flag of NvBlockSwComponentTypes and ServiceComponentTypes was not written to the ECU-Configuration file
  • DCF utility tool didn't support DCF workspace with AUTOSAR 4.1.3 schema
  • After using the function 'Adapt connected Ports' an error message 'Typeconflict (code 0x80020005)' was produced when opening the port properties.

(top)


DaVinci Developer Version 3.7 (SP3)

Tool features

  • Import of ARXML files with AUTOSAR schema 4.1.3 is now supported

Usability enhancements

  • AUTOSAR 3 import now reports an error if multiple component types reference the same internal behavior

Fixed issues

  • Create Port Prototype functionality sets the wrong package for existing data types
  • AUTOSAR 3 IMC import/update for a Multiple-Config project produced a 'fake' error message that renamed objects exists but no objects were actually renamed
  • AUTOSAR 4 import caused a stack overflow exception when importing an array without sub-elements
  • Init-Trigger handling was corrected to support legacy convention with a '0' cycle time

(top)


DaVinci Developer Version 3.7 (SP2)

Usability enhancements

  • Performance enhancement when loading communication data of a DCF workspace
  • Separate layout toolbar for direct modification of graphic port layout

Fixed issues

  • 'Substitute missing objects' functionality didn't work anymore with AUTOSAR 4 import files
  • Error message 'Invalid pointer code 0x80004003' was thrown when using "Create Port Prototypes" dialog
  • Crash fixed when creating a reference from PIM to NvMBlockNeed or the other way around
  • DaVinci Difference Analyzer command line didn't accept FlexNet license on 64bit Windows
  • Port defined argument values at Application Components couldn't be stored correctly in DCF format and AUTOSAR 3 export
  • AUTOSAR 3 import of enumerations didn't work if an enumeration value had the same name but a different position

(top)


DaVinci Developer Version 3.7 (SP1)

Fixed issues

  • The 'Last Import' timestamp in the ECU-Project's properties dialog was wrong if service components were loaded on opening the workspace
  • Unmodified software components where falsely updated on DCF saving if package information was imported which was actually the same
  • Import an existing software component with 'Keep Realization' option was wrong if existing ports with runnable accesses were deleted
  • When importing a communication specification of a composition port with an init value of type constant reference the reference was not set
  • When changing the kind of communication from queued to unqueued and vice versa, the corresponding communication specifications of ports were not updated on DCF saving
  • The 'Find unused Base Types' functionality didn't consider new references of mapped signals
  • Some ports were missing after import of an imc file for a multiple configuration project if a port with the same name but different port interface already exists
  • After import of the mecu file for a multiple ECU project the data mapping was incomplete if a signal group and their group-signals were mapped in different identities

(top)


DaVinci Developer Version 3.7

Tool features

  • General support for AUTOSAR schema 4.1.1 and 4.1.2
  • AUTOSAR 4 Port-Groups for definition of Virtual Functions Clusters
  • J1939-CLUSTER is now supported with AUTOSAR schema 4.1.1 and 4.1.2
  • Enhanced PDU design for Ethernet/IP-Cluster to allow PDUs without frame mapping
  • Create Port Prototype from data mapping based on a given signal as available for AUTOSAR 3 can now be used for AUTOSAR 4 too
  • Adapt Data Type for Data Element based on a given signal as available for AUTOSAR 3 can now be used for AUTOSAR 4 too
  • Various Service Needs extensions and GUI reworks with support of Role-Based port assignment
  • Improved definition of invalid value of application data types

Usability enhancements

  • Various improvements in roundtrip workflow between DaVinci Developer and DaVinci Configurator Pro
  • Some additional data-mapping and compatibility checks for AUTOSAR 4 data types
  • End-To-End Protections now have a default package like other design objects

Fixed issues

  • The 'check for differences' functionality created a new ECU-Project if the project name differed from the System Extract name
  • The 'check for differences' functionality is now disabled in project update use-case since it corrupted the workspace data
  • The data-type invalid value couldn't handle float values
  • Circular constant references caused a crash when opening such a constant in an editor
  • Incompatible init value was reported even if the data-types are compatible
  • DCF Utility couldn't handle AUTOSAR 4 DCF workspaces correctly and falsely reported corrupted ARXML files
  • Generic attributes of nested data types where incorrectly stored in AUTOSAR 4 DCF workspaces
  • DCF workspace couldn't be loaded anymore if a component type or ECU-Project contains an attached file

(top)


DaVinci Developer Version 3.6 (SP4)

Usability enhancements

  • Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
  • Enhancements in consistency checks for NV components
  • Import dialog now contains a simplified file/folder selection button
  • Additional consistency check to avoid data types referencing a data type with the same name

Fixed issues

  • Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
  • NV component couldn't be configured in the local composition view
  • Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
  • Blueprints couldnt be exported to DCF
  • Crash fixed if context component for create port prototypes was selected as "none"
  • AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
  • AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
  • The data type reference of a calibration element prototype wasn't set after import
  • Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
  • Copying a runnable broke the data model and causes undesired wait points
  • Duplicating an Object copied the original UUID instead of creating a new one.
  • HTML links in descriptions didn't appear in the report
  • Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.6 (SP3)

Usability enhancements

  • Category items in the Library Browser now have a 'Select All' functionality
  • Separate layout toolbar for direct modification of graphic port layout
  • Data Type Mapping Set dialog now supports multiple selection and modification through context menu

Fixed issues

  • Unmodified objects will no longer update files in the DCF workspace

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.6 (SP2)

Usability enhancements

  • Description field in property dialogs or property view now supports hyperlinks with link execution

Fixed issues

  • Local .CPG FlexNet license couldn't be checked out if multiple DaVinci Developer licenses are activated in parallel
  • ECU-C synchronization of OsSpinlock wrote invalid OsApplication-Refs
  • Exporting a nested composite data mapping failed and the ECU-Extract didn't contain the data mapping of the nested array
  • An ARXML export became invalid on exporting a symbol-value of component type which didn't fulfill the C-Identifiable pattern.

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.6 (SP1)

Usability enhancements

  • Enhanced display of information in the 'About Dialog' if no valid license can be found.
  • Performance enhancements during loading/saving DCF workspace and ECU-C synchronization

Fixed issues

  • Copy/Paste didn't work if the workspace path contains the "," character
  • Duplicate Software Component appeared in LibraryBrowser when re-opened the workspace after creating a workspace snapshot
  • The 'find unused' function for TypeMappingSets showed also elements in use
  • Workspace elements were editable even if the corresponding DCF arxml file was read-only
  • An exception occurred when importing an incomplete AUTOSAR 4 assembly connection
  • The size-property or record structure of nested array constants were not updated during import into a workspace already containing this constant
  • Error 'No such interface supported' with code 0x80004002 was shown twice when importing a Service-SWC by the file observation function
  • DataMapping contained a network signal without a name, message, and network, if a signal was part of at least two signal groups and each of them was received or transmitted on a frame
  • Implementation data types couldn't be deleted from within the Package View

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.6

Tool features

  • Support for Port-Prototype blueprints in the software design
  • Multi-core design is now supported by assigning a core to an OS-Application in AUTOSAR 3
  • N:1 communication is now supported in AUTOSAR 4
  • TP transmitted signals are now available for Data-Mapping in AUTOSAR 4
  • Support of NvData-Interface and NvBlock-Component-Types in AUTOSAR 4
  • System-Signals with 'dynamicLength' are now supported to address the specific use-cases for J1939 and IP
  • The AUTOSAR UUID attribute is now stored for all Objects for a better roundtrip support, new Objects can also be exported with a UUID
  • ARXML import of IP cluster descriptions also from AUTOSAR 4.1.1 format
  • The Vector AUTOSAR Explorer is now delivered as part of the DaVinci DEV setup

Usability enhancements

  • Enhanced interaction between DaVinci DEV and DaVinci CFG to detect renamed objects and refactured references accordingly
  • Support of externally defined service component files which are loaded automatically as read-only elements into DaVinci DEV
  • Some enhancements in aligning graphic elements and taken over attributes when copying graphic elements

Fixed issues

  • AUTOSAR 4 import falsely reported duplicate item names although the file contained unique names
  • AUTOSAR 4 import didn't overwrite the array size of an existing constant
  • AUTOSAR 4 consistency check falsely reported an incompatible End-to-End Protection although it was valid
  • Exporting a DCF workspace using DVImEx.exe threw an unknown error if the -s command line switch wasn't specified
  • Property view displayed wrong item after selecting a software component prototype

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.5 (SP4)

Usability enhancements

  • For graphic operations a UNDO functionality is now available
  • Definition of constants has been enhanced by supporting multi-selection and in-place editing
  • The HTML report now displays 'Queue Length: - ' if a data element is unqueued.

Fixed issues

  • GUI falsely allowed usage of multiple underscores for the record element name of record constants
  • GUI didn't allow leading underscore for the Symbol Values of Implementation Datatypes
  • AUTOSAR 3 import in 'Communication only' mode didn't set the correct package information and doesn't update dependent elements
  • Diff&Merge aborted with an unrelated error if the ARXML export wasn't possible
  • PDUs without package couldn't be merged during AUTOSAR 3 import if the workspace already contains the PDUs without packages
  • Error during DCF saving concerning consistency ID 40116 if a trigger name clash exists
  • Data mapping wasn't recognized in DaVinci Configurator Pro if DaVinci Developer setting 'use default packages' was enabled
  • During ARXML import the merge of existing Port-API Options was wrong if multiple port prototypes on different component types had the same name
  • Data mapping view showed superfluous group signal rows which cannot be unmapped if a signal group was mapped to multiple frames and the received group signal sets were different
  • ECU-C synchronization configured invalid Com callbacks if system signal was received by multiple frames and additionally as part of a system signal group
  • ECU-C synchronization showed a different ComSignal name postfix if the corresponding PDUs are configured as SplitTxRxPDUs and Tx-OverlayingPDUs
  • ECU-C synchronization reported invalid system signal references
  • Invalid ComSignal/ISignalToIPDUMapping references were falsely reported if the corresponding ISignalTriggering didn't reference a signal port
  • Component Prototype properties dialog couldn't be opened from within the component type selection dialog
  • Packages could be deleted without error message even if they are in use
  • Copying multiple elements in a list based view didn't work correctly and showed an error message

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.5 (SP3)

Usability enhancements

  • Enhanced display of information in the 'About Dialog' if no valid license can be found.
  • Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
  • New technical reference for AUTOSAR 4 Data Type design

Fixed issues

  • In rare cases the FlexNet license couldn't be checked out from a license server
  • Check for corrupted files in DCFUtility failed when using AUTOSAR 4 workspaces
  • DCFUtility showed "incompatible file version 0x6c00" error message when opening the ECU-Project binary file
  • Error occurred when importing an ECU SW-Composition port with a Com-Spec without init value
  • SUPPORTS-ASYNCHRONOUS-MODE-SWITCH = true leaded to missing port accesses
  • The generated Rte code contained wrong ComSignal handles and/or ComSignal handles were missing.
  • Loading a AUTOSAR 3 DCF workspace didn't finish in a reasonable time if End-to-End protections with deep SWC hierarchies existed

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.5 (SP2)

Tool features

  • New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU

Usability enhancements

  • Some AUTOSAR 4 specific basic data type checks have been implemented to ensure a valid base type, native declaration und unique naming
  • Data type map consistency check message with ID 30050 has been improved by showing the concrete data type which has to be fixed
  • The "Find Unsed Data Types" functionality has been improved to support all AUTOSAR 4 data type definitions
  • In multiple configuration projects, delegation ports with the same name but different data types are now automatically postfixed with the identity name

Fixed issues

  • After a new Project Assistant project has been created the corresponding workspace wasn't opened directly
  • AUTOSAR 4 import of connections didn't work for empty component types
  • Defined End-to-End connections to unconnected composition ports were lost during saving/loading a DCF workspace
  • Renaming of objects like Mode Declaration Groups didn't trigger all affected files to be updated in a DCF workspace
  • An existing Compu Method Reference couldn't be removed in the dialog by selecting the "none" entry
  • Init values at Inter-Runnable variables weren't checked correctly for data type compatibility
  • Timeout values with different units were reported as different although they were equal
  • Complex Device Driver were imported as a service component type if no service- or application-ports were defined
  • AUTOSAR 4 data constraints were not imported correctly if a compu-method specifies a compu-default-value
  • Some memory leaks during AUTOASAR 4 import have been solved, which caused a crash during load of the DCF workspace
  • Duplicated elements were imported if an element was defined in several files and contained sub-elements without a SHORT-NAME.
  • The NvMBlock length and RomBlock address was not adapted during ECU-C synchronization if the NvBlockDescriptor's NvBlockNeed length was greater than 0
  • Top-level connections derived from the data mapping were missing because the root composition in the ECU-Extract didn't contain connections
  • Data mapping of an array DataElement to a signal wasn't supported for AUTOSAR 4 application data types
  • Port prototypes, component prototypes and connections weren't deleted from the EcuSwComposition if the root composition type and/or package was renamed during updating the ECU-Extract
  • After an AUTOSAR 4 communication update obsolete signal groups were still mapped on a frame
  • Some communication elements were missing after opening a DCF workspace that contained PDU groups referencing other PDU groups
  • Internal exception thrown during AUTOSAR 4 import if the project contained a PDU with the same name as in the imported file, except for character case.
  • Message name in the data mapping view was missing if a signal was mapped on a PDU/Frame which contained signals mapped to several PDUs/Frames
  • Compilation of the generated Rte code failed because of missing Rte functions in multiple configuration projects using extracts of a Multiple-ECU project
  • Data IDs of different End-To-End connections were appended during update of a Multiple-ECU project
  • The Array constant definition was restricted to 512 elements in the GUI
  • The Rte generation showed an internal error about a missing COM signal if a signal was mapped standalone and as a group signal on different frames of the same cluster
  • Click on the "Copy" button didn't have any effect in the ECU Composition Port Prototype list view.
  • The "Adapt Connected Port Prototypes" functionality created invalid AUTOSAR 4 constant references
  • DaVinci DEV crashed when deleting a record element constant which contained duplicate elements

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal

(top)


DaVinci Developer Version 3.5 (SP1)

Tool features

  • Support for interrunnable variables with complex data types

Fixed issues

  • Exported of ECU-Extract contained invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters or frames
  • Wrong consistency check messages were shown after the first ECU-C synchronization
  • Rte generation failed with "internal error" if the workspace contained Nv ports and the workspace option 'Check and Generate Nv ports' was disabled.
  • ComSignal-names were not correctly imported from the ECU-C file for AUTOSAR 3 Multi-ECU or Multi-Config project.
  • The Software Component properties dialog cannot be closed if the Internal Behavior element contained a custom name without implementation element.
  • The MECU file of Multi-ECU project couldn't be imported if the 'MasterExtract' XML element contained additional elements e.g. comments
  • Crash on importing ECU-Extract fixed if End-to-End protections with END-TO-END-PROTECTION-I-SIGNAL-I-PDUS exists in the ARXML file.

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.5

Tool features

  • Definition of End-to-End Protection is now supported for ECU internal connections
  • Enhanced workflow support for the merge use-case: new Project Merge Assistant functionality available in the explorer context menu of a .dpa file
  • Support of Nv Data Interface and Nv Block Component Types in AUTOSAR 3
  • The SYMBOL property is now supported at the Software Component Type
  • For the online calibration the 'RAM buffer size' is configurable under Generation Parameters
  • Description at the COMPU-SCALE object is now supported

Usability enhancements

  • Setup of a new Project Assistant project will now create standard End-to-End Protection generation calls in the Generator list
  • DaVinci Developer component registration within Windows using the DaVinci Installation Manager is no longer required. Thus administrative rights are only required at setup time and no longer at runtime.
  • Large performance enhancement when merging software components with the 'Check differences before import' option
  • ECU Project report now contains more description fields

Fixed issues

  • Non-ANSI characters were located in the standard data type description; they are removed now.
  • The setting for 'UsesE2EProtection' will now always exported into XML, even if set to FALSE
  • Importing an existing AUTOSAR 4 port interface with a different 'IsService' setting no longer throws an exception
  • Creating a new AUTOSAR 4 project no longer throws an 'missing package reference' error when adding a new port prototype to the ECU Software Composition
  • AUTOSAR 3 import merged CompuMethods with the same name and package even if they were not equal
  • DVImEx command line tool didn't report an error if the specified item couldn't be found
  • Removing packages which were used within a ECU software composition didn't throw an error
  • Using 'Substitute missing objects' import option caused an exception if an application data type was resolved with a workspace element
  • The default package assignment during import was not correct for CompuMethods and Units
  • AUTOSAR 4 communication update removed an existing LIN cluster
  • Generic attribute export was missing for port prototypes at the ECU software composition
  • AUTOSAR 4 export aborted if an inconsistent port connection existed
  • The find function didn't find Enumerators and Record-Elements
  • Incompatible standard generator was reported when using command line Rte generator
  • Error dialog with message "Failed to create empty document." was shown during ECU Project report containing software compositions
  • Timestamp of observed external Service-Components were reset after workspace reloading when using DCF format
  • Crash in import dialog if observed Service-Component file were added twice and one of the duplicates was removed

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.4

Tool features

  • Automatic mapping of application- to implementation data types
  • Configuration of 'Mode Transisiton' runnable triggers is now supported
  • Design of pointer data types (DATA_REFERENCE) is now supported

Usability enhancements

  • In the software design the Tab-key can be used to step to the next design element of the same type
  • Some enhancements in grid alignment of connections and cross-sheet connectors
  • Enhanced info message to detect objects in different packages with the same name but different content

Fixed issues

  • Creation of circular references within record and array data types is now denied
  • Consistency check for missing application data type was only executed during Rte generation but not in the tool
  • Importing a data reference which does not specify an impl or target policy hasn't set the SwImplPolicy value to 'standard'
  • Rte validation and generation aborted with the message "Could not open file" if the temporary files folder contained too many files following the same name pattern.

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3 (SP5)

Tool features

  • Support of Signals has been added which were sent on several frames with several channels of a cluster

Usability enhancements

  • Naming of 'Symbol' attribute in data type dialogs has been clarified. The term 'Code Symbol' and 'Short Name' is now used instead.
  • Performance enhancement on import/check of data types

Fixed issues

  • List display of large number of port prototypes was incorrect when using cursor keys for navigation
  • Crash when pressing "n" in the Compu-Method dialog fixed
  • The communication specification attributes were incorrectly/not adapted on a destination port.
  • Some minor memory leaks fixed
  • In rare cases the automatic Data-Mapping switched the sub-element mapping of signal groups

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3 (SP4)

Tool features

  • New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU
  • Port Defined Argument Values are now available at Application Components

Usability enhancements

  • Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
  • Init-Runnable annotation is now supported in AUTOSAR 4 Admin-Data export
  • Category items in the Library View now have a 'SelectAll' function

Fixed issues

  • Editing port accesses using multiple selection led in a dialog error
  • AUTOSAR 3 import of enumerations didn't work if an enumeration value had the same name but a different position
  • Existing SWC implementation was removed during AUTOSAR 4 import if a SWC with the same name and empty structure was imported
  • Internal data constraint couldn't be edit if set to -INF or +INF
  • Error message 'item not found' during AUTOSAR 4 import fixed if an existing data type with compu-method was updated without a compu-method
  • Wrong export of constant-reference item fixed if it actually didn't reference a constant
  • Wrong export of the DEST attribute fixed if the component type is a complex device driver
  • The data-constraint reference wasn't saved on closing the dialog with 'OK' after creating a new calibration element prototype
  • Crash on re-opening a DCF workspace fixed that was caused by memory leaks
  • Name clash fixed during export of End-to-End protections on atomic ports
  • The 'Adapt connected port' functionality didn't consider all communication specification values like 'EnableUpdate'
  • Consistency check message #40329 'unsupported N:M communication' wasn't displayed anymore
  • Mapping of single signal to nested arrays and vice versa didn't work correctly
  • Task property 'generate schedule calls' wasn't stored in the ECU-C file
  • Invalid ComSignal/ISignalToIPDUMapping references were falsely reported if the corresponding ISignalTriggering didn't reference a signal port
  • CalibrationSupport flag wasn't written to the ECU-C file for all atomic software components
  • In some cases the 'Find Results' properties opened the wrong property dialog

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3 (SP3)

Tool features

  • End-to-End protection resynchronization flags are now supported for AUTOSAR schema 4.0.3
  • Data Mapping of single signal to array data types is now supported if the array is part of a complex structure
  • Import feature "check for differences" is now available for AUTOSAR 4 Software Component Types

Usability enhancements

  • Misleading general import message "Ignoring internal data constraints" is now replaced with a more specific one if the data constraints are incompatible
  • Starting from an existing port it is now possible to create a foreign port, including a necessary connection
  • Copy&Paste of Data-Element-Prototypes and Port-Prototypes is now supported from one interface/component to another
  • The automatic data mapping has been enhanced to match sub-strings with the biggest possible string length
  • The 'adapt connected port' function has been enhanced with additional options

Fixed issues

  • The default package path assignment to CompuMethods and Units was wrong
  • The properties button in the data selection dialog didn't work for AUTOSAR 4 data types
  • Wrong import of indexed elements (e.g. Record-Elements) has been fixed if the elements have temporarily the same name during import process
  • Import of Revision-Label at the InternalBehavior element was missing
  • Consistency check was not correctly executed for Calibration Communication-Specifications
  • The item locking state was not corrected stored for packages in DCF workspaces
  • In ARXML export of DCF saving the generic attribute IMPORT_MODE_PRESET was missing at the ECU-SW-Composition delegation ports
  • When importing an updated ECU-Extract an existing LIN-cluster was deleted.
  • If the delegation port of an ECU software composition was inconsistent the ARXML export aborts with error message 'Internal exception occurred: The connection is missing a valid transmitter or receiver port'
  • The Runnable Operation Access was not imported using a AUTOSAR 4 SoftwareComponentType in "overwrite" mode
  • The Component Type dialog not forbids setting the 'supportsMultipleInstantiation' flag for Service SWCs.
  • Internal exception during ARXML import has been fixed if an application data type was resolved using a workspace element
  • The package import mode workspace and session setting was ignored by the ARXML import dialog. Thus it always selected the package import mode 'import from file'
  • The ModeDeclarationGroups dialog was not correctly updated when explicit values of a mode have been changed
  • The color highlighting of compatible ports was not consistent during manually drawing of a connection

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3 (SP2)

Tool features

  • Cross-Importer is now available to import AUTOSAR 3 software components into an AUTOSAR 4 workspace
  • End-to-End protection resynchronization flags are now supported for AUTOSAR schema 3.2.2 and 3.2.1
  • Calibration communication specifications are now supported on Compositions too

Usability enhancements

  • Constant selection dialog now additionally displays the constant value
  • Workspace format has now to be chosen explicitly when creating a new workspace
  • Some consistency checks have been enhanced to detect usage of identical names that lead into Rte generation errors
  • XML-Importer Output messages have been improved to display more context information
  • Separate consistency message details dialog has been replaced by an in-place display in the messages tab

Fixed issues

  • "Save As..." didn't work if .dev workspace file was set to read-only
  • Consistency check ID 20013 was thrown on invalid argument prototype which was not visible in the GUI
  • Cryptic open workspace message was shown in the action log when using DCF workspace in a DPA project
  • Item information was missing in the data type unit check message
  • Find functionality didn't fully support AUTOSAR 4 types
  • Obsolete menu entries appeared in AUTOSAR 4 design mode
  • AUTOSAR 4 PARAMETER-PROVIDE-COM-SPEC was is not exported
  • COM-Callbacks couldn't be configured depending on the 'enabledUpdate' setting
  • Several problems concerning missing elements have been fixed in the AUTOSAR 4 import/export
  • Crash in converting old .dev workspace fixed if inconsistent objects exist
  • AUTOSAR 4 EcuAbstraction- or ComplexDeviceDriver were imported as services even if they used application ports
  • AUTOSAR 4 import with "Substitute missing objects" didn't work with mode declarations

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3 (SP1)

Tool features

  • The 'Enable Update' is now supported at the communication specification to configure the Rte_IsUpdated functionality
  • N:1 Sender/Receiver Intra-ECU communication is now supported in case no internal senders were used
  • Reporting of ECU Extracts and Software Components is now fully available for AUTOSAR 4
  • ARXML export in schema version 4.0.2 is now available

Usability enhancements

  • Definition of record order index can now be simply configured by moving the elements
  • A separate icon has been introduced in the graphic for Nv Data Port Prototypes

Fixed issues

  • Wrong check message for open delegation R-Ports without init values has been fixed
  • End-to-End protection information was not fully imported/exported for AUTOSAR 4 format
  • The option ''Overwrite import mode preset' didnt work for AUTOSAR 4 import
  • The 'create port prototype' functionality in the data mapping view failed with the message 'invalid pointer 0x80004003' when using signal groups
  • A new workspace couldn't be created based on a Multiple Configuration project setup
  • Superfluous Operation Argument Prototypes were not deleted when importing an ARXML file
  • An invalid ARXML file was exported if the configuration contains diagnostic communication needs
  • A modified software component graphic was not stored if the component type was locked during the graphic editor was open
  • New calibration element prototypes could only be created by pressing 'Apply' in the dialog and not with 'OK'
  • The properties window didn't display the signal attributes of the selected network signal in the data mapping view
  • Multiple Configuration files couldn't be imported because the XML import dialog reported that the selected *.imc/*.mecu file was not supported.
  • Unconnected Calibration Ports caused a Rte generation error
  • AUTOSAR 4 export wrote lots of empty XML element tags
  • A check was missing to report that a Service Mapping should not allow N:1 Client/Server communication

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types

(top)


DaVinci Developer Version 3.3

Tool features

  • Workspace design mode: AUTOSAR 3 or AUTOSAR 4
  • Import/Export of AUTOSAR 4.0.3
  • Import/Export of AUTOSAR 3.2.2
  • Support of DaVinci Configurator 5 projects: hide RTE configuration features
  • Import of frames with multiple frame triggerings
  • Selective import (communication only)
  • AUTOSAR 4
    • Support of data type model (Application Data Types, Implementation Data Types, Base Types, Type Mapping Set)
    • Definition of constants as value without type reference
    • Compu Method, Unit and Data Constraint as library objects
    • Selection of included data types in context of a component type
    • Selection of data constraints and handle-invalid settings for data element prototypes
    • Local definition of init values constants in the communication specification
    • Definition of symbol for component types and data types
  • AUTOSAR 3
    • Support of NV Data Interface
    • Support of Daimler E2E profiles

Usability enhancements

  • Import Dialog: display AUTOSAR version of selected files
  • Import Dialog: allow import of a file set with differing AUTOSAR minor versions
  • Allow unconnected delegation ports (info instead of error message)
  • Allow unconnected calibration R-ports
  • Init value can be omitted, if the init value is defined at the connected port
  • AUTOSAR 3: Display resulting physical range of a data type depending on the scaling

Limitations

  • For AUTOSAR 4 design the following functionality is currently not available:
    • Create Port Prototype from data mapping based on a given signal
    • Adapt Data Type for Data Element based on a given signal
    • Find unused data types
    • Reporting of ECU-Extracts or Software Components

(top)


DaVinci Developer Version 3.2 (SP7)

Tool features

  • Maximum enumerator name length has been increased from 255 to 32767 characters
  • Support of Signals has been added which were sent on several frames with several channels of a cluster

Fixed issues

  • In rare cases the automatic Data-Mapping switched the sub-element mapping of signal groups
  • It was falsely allowed to add a second composition to an ECU-Project using Drag&Drop
  • The Library's package view was not updated when creating a new root package within the package selection dialog

(top)


DaVinci Developer Version 3.2 (SP6)

Tool features

  • Support of UUIDs on import/export at additional elements has been added

Usability enhancements

  • Automatic service mapping has been enhanced to get better sub-string name matching

Fixed issues

  • Autoconnect popup menu was corrupt and contained empty and wrong entries
  • Option to show strict compatible ports only must be toggled to had an effect
  • Rte code contained a wrong com signal (group) handle: the handle of a transmitted ComSignal is used instead of the handle fo the received ComSignal.
  • A DCF workspace couldn't be opened anymore due to invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters/frames
  • Error message "Invalid pointer code 0x80004003" was thrown when using "Create Port Prototypes"

(top)


DaVinci Developer Version 3.2 (SP5)

Tool features

  • Task Mapping has been improved to read the Schedule Manager configuration from the ECU-C

Usability enhancements

  • Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
  • Automatic data mapping has been enhanced for Group-Signals with better name matching

Fixed issues

  • Copy&Paste keyboard support (Ctrl+C and old Ctrl+Ins, ....) was missing in the output window
  • Consistency check crashed in rare cases if the model contains unresolved references, e.g. caused by an import of an inconsistent ARXML file
  • Calibration-Access of queued communication was exported with the wrong default value which should be 'not accessible'
  • Misleading Action-Log message: 'CONTAINER /ActiveEcuC/Os/osSystemApplication: Os resource reference /ActiveEcuC/Os/RES_XYZ could not be resolved.' was reported
  • Closing a dialog with "Cancel" initiated superfluous GUI updates on unmodified data
  • 'Adapt Data Element to Signal' or 'Create Port Prototypes' falsely modified the record element order
  • A software component was displayed twice in the graphic when dropped into a composition
  • Export of ECU-Extract contained invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters or frames

(top)


DaVinci Developer Version 3.2 (SP4)

Tool features

  • New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU

Usability enhancements

  • End-to-End Protections can now be re-assigned to another port and remain existent if the Data-Element-Prototype is removed
  • During data mapping an existing data type is now automatically reused in the 'Create Port Prototype' functionality if the name and primitive types matches the new mapping
  • The selection in the data mapping editor now remains, when opening and closing the 'Create Port Prototype' dialog
  • Drag&Drop of multiple selected ports have been enhanced to keep their left/right position
  • Delegation Ports can now be located automatically when positioned on several sheets and shifted to a sheet manually when unconnected

Fixed issues

  • Crash in generic data selection dialogs fixed if the dialog was closed with a double-click without a selected item
  • The Copy&Paste command from the context menu didn't work in the library window
  • The RTE Generation aborted with the error 'An entry with the same key already exists' when an Application Error of an Operation Prototype was not uniquely named

(top)


DaVinci Developer Version 3.2 (SP3)

Tool features

  • Display and edit of Port-Access and Trigger Short-Names of runnables are now available in the GUI

Usability enhancements

  • Create ports from signals now allows direct specification of packages for the newly created objects
  • ECU-Project and SWC report has been enhanced to display description fields
  • Trusted functions, which weren't added by the RTE (without the 'Rte_' Prefix) are no longer displayed as error in the ECU-C synchronization difference view
  • ARXML import performance using ''substitute missing objects' option has been significantly improved
  • Separate consistency message details dialog has been replaced by an in-place display in the messages tab

Fixed issues

  • Incompatible standard generator was reported when using command line Rte generator with an ECU-Project that didn't contain a generator definition
  • Crash occurred while loading ECU-C file of a DCF workspace if the ECU-C file was split into module specific files but the main ECU-C was empty, i.e. all module definitions were missing
  • Error dialog with message "Failed to create empty document." was shown during ECU-Project reporting if it contained hierarchies of Software-Compositions
  • Button on a background view falsely worked on currently active view if two overlapping software component views were opened
  • The info message (40288 DataType with the same name as a platform type) created for a DataType/Constant was propagated to the SWC as an error
  • VFB Trace functions weren't correctly stored in DCF format if no other workspace modifications have been done.
  • Crash occurred when importing an incomplete AUTOSAR file containing a SYSTEM but neither an ECU-INSTANCE nor an ECU-SW-COMPOSITION
  • DVImEx didn't report a message when the specified item was not found in the data
  • The find function didn't find Enumerators and Record-Elements
  • The GenerateStub setting was overwritten even if a user configured value exists
  • The operation call return trigger was removed from the ARXML if several runnables were triggered by the same operation call return trigger.
  • Group-Signal selection for data mapping didn't show signals if the data mapping view is in 'Data-Element' perspective
  • Connection was deleted during ARXML update although one of the connected port prototype's import mode was set to 'keep'

(top)


DaVinci Developer Version 3.2 (SP2)

Tool features

  • Configuration support for End-To-End Protection resynchronization added
  • Configuration of Rte generation parameters is now also available for Service Components
  • Workspace checker command line tool got the new option '-s' to save the check modifications to the workspace

Usability enhancements

  • Enhanced display of consistency check messages to allow grouping of similar messages by their ID
  • ARXML import dialog now allows import of multiple files with different AUTOSAR 3.x schema versions
  • Data type dialogs now display the physical ranges according to the configured scaling information
  • Graphical Cross-Sheet Connectors now display the full port name with Component Prototype context
  • Delete objects of different types with multi-selection is now supported

Fixed issues

  • Memory leaks removed when loading/saving DCF workspace
  • Port interfaces without data element prototypes caused empty element tags in the exported ARXML file
  • Using the filter in the object selection dialog removed the package display
  • ECU Project graphic display caused a memory corruption

(top)


DaVinci Developer Version 3.2 (SP1)

Fixed issues

  • Loading a DCF workspace aborts with error message "Unknown Interface" if an obsolete task mapping was defined in the ECU-C file that refered to a deleted runnable or a deleted task
  • Rte generation aborted due to inconsistency warnings threw by the Rte generator, which were tolerable in specific cases
  • Rte generation aborted due to inconsistent record constant structure
  • ARXML import crashed if a Signal-Group and a Signal caused a namespace conflict
  • Missing object references in the ARXML file couldn't be resolved with existing workspace objects using "check for differences" option. This option is now disabled because "substitute missing objects" cannot be used when merging the objects.
  • USB dongle access caused GUI freeze in some situations

(top)


DaVinci Developer Version 3.2

Tool features

  • New Software Component Type to define End-to-End Protection Proxy Components

Usability enhancements

  • Additional export Option added to omit the End-to-End Protection Configuration in the exported ARXML

Fixed issues

  • Import of ARXML packages had overwritten existing package content instead of merging it
  • Multiple Configuration projects couldn't be created if different package structure exists in the input files
  • Root package could be illegally moved into an existing package structure that results in a deleted package even if the workspace wasn't saved
  • Signal and Signal-Groups weren't allowed to have the same name. This limitation has been removed.

(top)


DaVinci Developer Version 3.1 (SP4)

Usability enhancements

  • "Unmap Signal" in the context menu of the Data-Mapping view now supports multi-selection
  • Rte trigger and runnable offset properties are now displayed in the properties view when selecting a task mapping table cell
  • The "Show ..." option settings in the Data-Mapping dialog are now remembered between dialog sessions
  • Multi-selection is now supported for complex constant values via In-Place editing
  • Enhanced check for unique C-Symbols in generated Rte code to detect name inconsistencies prior to Rte generation
  • Import dialog options are now persistently stored in the workspace to restore them as default on the next dialog session

Fixed issues

  • Factor and offset of a data type scaling was mot imported if the ARXML didn't contain a denominator definition at the CompuMethod
  • Modification of read/write generic attributes cannot be stored because the Data Element Prototype was read-only
  • Loading DCF workspace consumed large amount of memory
  • DataSendCompletionTrigger caused a missing Rte-Event reference error in the ECUC-Sync dialog.
  • ECU-Project report didn't work for read-only workspaces
  • Create DPA project out of existing files failed in DaVinci DEV if no workspace was selected
  • Graphic was missing in the HTML report for newly created software components
  • Rte generation ran out of memory when using huge complex data types
  • The user defined block size on the NvNeed was not used for the ECU-C Synchronization. Instead a wrong calculated value was used.
  • DCF workspace save was prevented by check message due to inconsistent import
  • Adapt data element to match signals was not available for complex types
  • Import of record constant caused unresolved reference error if obsolete record elements were referenced
  • Under some circumstances newly created elements didn't get unique names within their package namespace
  • The special import 'Overwrite import mode preset' didn't work with read-only items
  • Manual service mapping allowed creation of redundant connections
  • Import aborted with COM-error 'Invalid parameter' due to an unsupported encoding
  • Adapt port prototypes function didn't copy the E2E and HandleNeverReceived settings
  • DaVinci DEV runs out of memory because of memory leaks when saving DCF workspace. For DaVinci DEV 3.1 SP4 some leaks have been fixed but there still exists some more that will be fixed in a later version.

Limitations

  • AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.

(top)


DaVinci Developer Version 3.1 (SP3)

Tool features

  • Report generator for ECU Projects and Software Component Compositions
  • Full import of communication data from ECU-Extract defined with AUTOSAR schema version 4.0

Fixed issues

  • Tool crashed because incompatible newer workspace could be opened with older tool
  • Import aborted with "unknown error 0x80004005" if the ARXML file was located in a path containing Japanese characters, e.g. a folder on the desktop
  • Some consistency check messages were not displayed in the messages tab after Rte code generation
  • If the workspace was read-only the code generation couldn't be started because the generation dialog was read-only too
  • USB dongle access caused GUI freeze in some situations

Limitations

  • AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.

(top)


DaVinci Developer Version 3.1 (SP2)

Tool features

  • Import of Software Components and ECU-Extract defined with AUTOSAR schema version 4.0

Usability enhancements

  • Better performance and improved layout of Software Component report

Fixed issues

  • First service mapping was not displayed in the service mapping tree if more than one mapping information exists
  • If a package has been moved within the package hierarchy the saving of a DCF workspace didn't save all package related items. This resulted in an error on loading the DCF workspace.
  • Snapshot of a newly created DCF workspace didn't contain read-only information of data-types
  • Workspace modified flag had been reset after creating a snapshot
  • DCF workspace was not properly saved if a packages was renamed
  • Properties view didn't display information for Atomic-Prototypes

Limitations

  • AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.

(top)


DaVinci Developer Version 3.1 (SP1)

Fixed issues

  • DCF workspace couldn't be loaded due to an AUTOSAR schema violation if item short-names started with an underscore or a number
  • Error message "Type library is not registered" was thrown on opening a workspace when DaVinci Developer 3.1 and 3.0 were installed in parallel on the same PC and an active 3.0 installation has been switched to 3.1 using the DaVinci Installation Manager
  • Component Types were missing on DCF loading because of ambiguous names within a package
  • It was unable to rename an item if the name differed only in character case
  • ARXML export using DVImEx failed with workspace read-only error if DVImEx was started from within DaVinci Developer to export from the currently opened workspace.
  • Rte synchronization was started even if the workspace was inconsistent
  • Invalid record constant has thrown an "Unknown pointer" error during the consistency check of an ECU-Project

(top)


DaVinci Developer Version 3.1

Tool features

  • Report generator for Software Components
  • Support of AUTOSAR Byte-Arrays as primitive data-type
  • Support of AUTOSAR Packages

Usability enhancements

  • Specific Hex-Editor dialog to define string constants with non-printable characters
  • Network signals without frame-mapping can now be used for data-mapping

Fixed issues

  • Tool crashed during ARXML import into DCF workspace if the workspace files are read-only
  • Rte generation failed if Signal-Group degradation with internal and external receivers existed
  • No more error during backup restore after Project Assistant update, caused by the workspace still being used by DaVinci Developer
  • Command line Rte generator falsely used the Rte Generator defined at the ECU-Project in the workspace
  • An error dialog was missing when a constant was about to be deleted in the Library-Browser which was still in use by a signal

(top)


DaVinci Developer Version 3.0 (SP5)

Tool features

  • Support of AUTOSAR schema version 3.2.1
  • Introduction of object locked state to specify objects as read-only for tools editors and ARXML import
  • A Port-Terminator has been introduced to distinguish between intentionally and unintentionally unconnected ports
  • Configuration of the 'Handle Never Received' flag at the receiver communication specification added
  • Configuration of the 'Uses End-to-End Protection' flag at the sender/receiver communication specification added
  • Configuration of the 'Calibration Access' at the argument prototype of client/server port interfaces added
  • End-to-End connections are now allowed for mixed internal and external receivers
  • Service Software Component files can now be added to an observation list at the ECU-Project to automatically detect file modifications
  • Creation of Support Request Package can be started from File-Menu to pack support relevant information into a ZIP-File
  • Additional End-to-End Protection profiles to configure specific safety wrappers
  • In the Task Mapping a dedicated timing requirement can be configured at a task, to ease the configuration of timesliced systems
  • Difference Analyzer is now able to optionaly display added / removed / equal objects instead of displaying the differences only
  • Workspace snapshots can now be created at any point in time to store intermediate copies of an open workspace. By restoring a snapshot the content of the workspace is rolled-back.

Usability enhancements

  • New option in ARXML import dialog to resolve open references in ARXML files against existing objects in the workspace
  • Depending on the 'allow generation of unsaved data' setting and the version compatibility of the RTE the user will be asked if the workspace should be saved and then automatically continue with the current action.
  • If the "Synchronize workspace with ECU-Configuration file when loading a workspace" is deactivated an additional message is now shown if the ECU-Configuration file has been changed while DaVinci DEV was closed.
  • When creating a Schedule Manager task in GENy, DaVinci DEV now automatically assigns the role "BSW Scheduler" to this task
  • Generation dialog has been reworked to show more detailed generation process and error display
  • A configurable check has been added to detect if the Invalid-Value lays within the Data-Type Range
  • To allow an import, ServiceSWCs are converted automatically to ComplexDrivers if used in a regular Composition
  • The command-line importer can now handle several ARXML files in one import step
  • Harmonized the XML formalization of the ECUC-file in all Vector AUTOSAR tools

Fixed issues

  • An error message was thrown when selecting a huge number of files (> 1000) for import in the file open dialog
  • The modification state of the ECU-C file was checked too often under Windows 7
  • Port defined argument values with the same name couldn't be imported at different ports of the same software component
  • The category attribute was not exported at the CompuMethod
  • AUTOSAR XML import aborted with "item is read-only" message if an object with the same name was part of several AUTOSAR XML files and defined in different AUTOSAR packages.
  • Mapping of ECU delegation ports was missing in the exported ARXML if the port was not connected to a component type
  • Tool crashed when the Software Design was opened after referenced port has been removed during ARXML import
  • Color Highlighting of compatible ports in the structure graphic didn't work correctly with several instances of the same Component Type
  • Init value specification at Calibration Parameter Com-Spec was ignored in consistency check and Rte code generation
  • Different interpretation of file order in the Multiple-ECU overlay file causes error in ECU-C synchronization
  • On certain unresolved references to Mode Declaration Groups or Modes itself the import was aborted
  • The consistency-check for ambiguous short names in the exported ARXML is no longer case-sensitive
  • When the short name of a child element was removed or not unique the according message dialog might have reappeared endlessly
  • The OSApplication assignment to a Task is now stored in the ECUC-file even when no other OSObjects can be determined due to consistency errors
  • Checking of differences during ARXML import aborts if ModeExecutionInhibitor objects are defined at the runnable
  • Wrong error message in data mapping compatibility check has been thrown if the first record element was not mapped to a group signal
  • In some cases the DCF workspace save runs out of memory if the software component structure of the ECU-Project contained lots of Compositions if a deep hierarchy
  • The use invalid flag and scaling flag at the data types were not reset during import if there was no semantics information defined in the ARXML file
  • In rare cases DaVinci DEV crashed during ECU-C synchronize if a port prototype has been deleted while it was referenced by a Data-Reception-Trigger.
  • XML Parser error was thrown on Service Component update if an observed Service Component ARXML file was deleted
  • Reference to an AUTOSAR constant couldn't be resolved using an existing constant from the workspace
  • Com-Callback was missing for the "handle never received" and "End-to-End protection IsUpdated" use case
  • Misleading inconsistency message was thrown on ECU-C synchronization if NvM configuration was out of sync
  • Rte generation was always aborted even if the stop button has not been pressed in the current generation process
  • ARXML import of a complex constant produced an 'Unknown Error' the referenced complex data type was imported from a different file
  • Generated Rte code was invalid if a predefined standard data type was renamed to a predefined platform type, e.g. UInt32 -> uint32.
  • In case of a split ECU-C project the Rte/NvM/Os module configurations were accidently added to the central ECU-C file and to the module specific ECU-C file.
  • Template- and Contract-Header generation from the SWC-context menu didn't work for DCF workspaces
  • The ARXML import in mode 'Overwrite' crashed due to an unresolved reference to a Mode-Declaration-Group
  • Diff/Merge didn't import Port-API Options correctly
  • ARXML import crashed in resolving missing reference by the substitute functionality
  • Consistency check message 40231 was thrown because of wrong offset calculation
  • In rare cases creating a new workspace crashed on Windows 7

(top)


DaVinci Developer Version 3.0 (SP4)

Tool features

  • Definition of End-to-End Protected connections available at the ECU project delegation ports to enable external generation of safety wrappers
  • Port defined argument values (PDAV) can now be edited at the service component ports
  • Enhanced compatibility with MICROSAR RTE generators allows usage of previous Rte version 2.17.2 (and newer) as external generator for this DaVinci Developer release.
    You can find a detailed overview with the compatible MICROSAR RTE versions at www.vector.com/rte_davinci

Usability enhancements

  • Icons of the various DaVinci tools got a unique abbreviation to differentiate the tools more easily
  • Check message export function has been enhanced with the detailed description and respects now the sorting order as specified in the list view
  • Creation of mapped signal ports can now additionally create Software Component ports and connect them to the created ECU-Delegation port

Fixed issues

  • ARXML import of complex Data-Mapping was incomplete if an array data type to a signal group contains or is contained in another complex data type
  • ARXML import of complex constants with CONSTANT-REFERENCEs was not correct
  • Update of existing workspace with an ARXML import failed if a referenced Port-Interface or Mode-Declaration-Group was missing in the ARXML file
  • If a service server port is mapped to a client port, it was not possible to map the port from the server side to another client port
  • Consistency check of delegation connector ComSpec on ECU top-level was missing
  • Consistency check #40259 created an inconsistency message even if the error trigger was correctly used with invalid handling
  • Automatic creation of ports in data mapping failed in case of partially received signal group
  • Consistency violation reported if scaled signal was mapped to an opaque data element
  • Connectors in connector prototype list view were missing if a connector merge scenario was designed
  • Relocation of a connection to a compatible delegation port was not visible due to missing graphic update
  • DaVinci DEV freezes on certain handlings in the graphic if a large graphic model without sheets is designed
  • Connection inconsistency error occurred due to wrong model update when changing the Component Type of a Component Prototype
  • Service Mapping didn't show compatible ports correctly when using the 'show compatible Ports only' option in the selection dialog
  • In some cases an error message was thrown during import update of LIN cluster with Sporadic Frames
  • Import of Port Defined Argument Values with the same name was not possible
  • Superflous COM_SendSignal calls existed in Rte code if the same System-Signal was mapped to several Tx/Rx-Frames
  • Wrong consistency check message fixed that the Rx-Signal bit length didn't fit into the data element

(top)


DaVinci Developer Version 3.0 (SP3)

Tool features

  • Microsoft Windows 7 is now supported
  • DaVinci Installation Setup now allows maintenance of an existing installation and installation of a new instance in parallel with the same Service Pack version
  • Parameter for RTE online calibration can now be configured in the context of the 'Generation Parameters' View
  • Enhanced handling for Signal-Groups to allow that a receiver of a Signal-Group / complex Data-Type receives only a subset of the data
  • DaVinci Project Assistant now supports setting up projects on DBC, LDF, FIBEX files that will automatically converted into an AUTOSAR ECU-Extract
  • DaVinci Developer can now work on ECU-C files which are split into module specific files to allow different users to work on different modules in parallel
  • Extension of Multiple-ECU support to explicit overlay Tx/Rx signals and allow PDU overlay of PDUs with optional signals
  • New dialog for automatic connection of ports with enhanced matching algorithm and selection of desired connections in prior to apply the auto-connect
  • For Project Assistant projects the DaVinci workspace format can now be changed from DEV to DCF and vice versa
  • New command-line tool DVWspChecker, which allows consistency checking of an ECU-Project or Component-Type in the specified DVW- or DCF-workspace
  • New configuration option to disable the init value check for unused ports (without port-access and without calibration parameter).
    IMPORTANT NOTE: disable the check requires MICROSAR RTE version 2.17.2 for correct code generation
  • DaVinci Project Assistant now support creating of projects based on existing non-DPA projects and creation of DPA-projects with module-split ECU-C files

Usability enhancements

  • Ports list view is now available for ECU Software Composition
  • OS-Counter parameter will now initially set to Os/SystemTimer when creating new Alarms
  • Consistency message results can now be exported into a log file
  • DaVinci Project Assistant menu and Model Check menu is now available even if ECU-Project sub-items are selected
  • Service mapping update no longer closes the complete editor tree after editing service mappings
  • Graphical connections are now highlighted when selected a port or a cross-sheet connector
  • Navigation in Software Design editor is now possible by clicking on a delegation port

Fixed issues

  • Float number format in ECU-C has been adapted to match format used in DaVinci Configurator Pro and GENy to avoid file differences
  • Fixed importing an ECU-Extract using the Diff&Merge feature to avoid corrupted communication information due to wrong merge algorithm
  • ECU-C file consistency dialog no longer opens up when saving the workspace
  • Obsolete check message is no longer displayed after fixing an inconsistent Data-Element-Prototype at the Component-Type's port
  • Errors message for unconnected ports and non-matching Data-Element-Prototypes are now split into separate specific messages
  • In some cases the DaVinci DEV application couldn't be closed through the task-bar menu
  • Alive timeout handling was falsely enabled if the value was set to 0.0 instead to 0
  • In some cases an editor update was missing on creation/deletion of runnables
  • Service Need names were not checked for uniqueness
  • ComSignal(Group)s were not found in ECU-C in the Multiple-ECU configuration of PDU as Overlay-PDU which contains optional signals in the master ECU-Extract.
  • File version checking of the MECU schema version has been corrected
  • During ARXML import the remember-option is now disabled on special import mode condition, if only new-mode is allowed
  • RteEvent references will now correctly resolved if ECU-C uses short names with 32 chars but ECU-Extract uses short names with 128 characters
  • DCF load aborted when the DCF AUTOSAR version was different from the ECU-C AUTOSAR version
  • In some cases DEV requested an ECU-C lock although it was not the active application
  • Bugfix in the placeholder replacement of $(GENDATAFOLDER) when the following character is a double quote
  • ECU-Project consistency check crashed if several runnables exist which were triggered by an OnModeEntry event
  • AUTOSAR Import/Export ignored the Communication-Specifications at the ECU delegation ports
  • Missing popup menu entries at ECU-Project Connector-List editor for changing port prototypes
  • Installation setup has defined wrong working directory entry in the DaVinci Developer desktop link
  • ARXML import created Enum-Types without enumerator instead of Integer-Type if the scaling at the data type had defined an own range
  • DCF workspace couldn't be saved if multiplexed communication was used
  • DaVinci Difference analyzer stopped with error 0x800407D0 in XPath Expression at xsl:if "Too many items - string" if calibration parameter init values were defined
  • In rare cases the ECU-C synchronization moves the ECU-Configuration tag in the ARXML file if a module configuration (e.g. of a 3rd Party module) in the ECU-C file exists, that has a Short-Name that comes in the alphabetical order before the 'ActiveECUC' Package.
  • ARXML import aborts with E_FAIL error code when importing renamed record data-types referenced by record constants
  • Wrong ComSignal handles in Rte because ARXML import didn't update the message to signal relation correctly in overwrite import mode.
  • Main window could not be restored if it was minimized running on Windows 7
  • Wrong Init-Value consistency check message was reported if obsolete communication specifications existed
  • Wrong display of some dialog controls on Chinese Windows has been corrected
  • Auto-Connect created a connection between C/S and S/R which resulted in a consistency error
  • Auto-Mapping has created wrong or inconsistent signal group mapping if naming rules and compatibility of elements was ambiguously
  • If NvM memory blocks were configured and the according NvM service component was imported the consistency check may have been crashed.
  • Rte callbacks were missing if the same system signal was mapped on Rx and Tx port
  • Response on GUI actions was very slow and had 1-2 seconds latency when using Vector USB Dongle license
  • Setup threw an error message that product isn't installed when using the repair option
  • Constraints and Limits properties of the data element prototype were ignored when importing
  • In rare cases DCF load restored a wrong order index of the Task-Mapping
  • Unintended message was shown if the ECU-Configuration file has been changed while closing DaVinci workspace
  • Top-Level connections were not correctly removed during ECU-Extract update
  • Obsolete ModeDisablingDependencies were not removed correctly during import
  • Import of Multiple ECU Extract aborted with 'Item already in Set' error
  • Save Workspace As failed, if the workspace was read-only because it was created with a newer DaVinci version.
  • ARXML import of incorrect MODE-DEPENDENCY aborted with "Unknown error" instead of printing an error message
  • Special import feature couldn't be executed if a Project Assistant file was referenced in the ECU-Project
  • An update of an ECU-Project failed with the message "Invalid argument" if a mapped Per-Instance-Memory wasn't overwritten due to the Import-Mode-Preset attribute
  • Import of incorrect EXCLUSIVE-AREA-ACCESS aborted with "Unknown error" if the references to the exclusive area was invalid
  • If the P-Port was a delegation port of a SW-Composition it was unable to connect an R-Port because of wrong incompatible direction error message
  • If multiplexed ECUs exists the DaVinci DEV added ComSignal callbacks to the ECU-Configuration but the functions are not generated by the Rte generator
  • Rte generation failed with an internal error if an ARXML with multiple mapping of the same system signal has been imported in prior
  • After loading a DCF workspace the data mapping was lost for delegation ports which received a subset of a signal group
  • ARXML import crashed if LIN event triggered frames were imported
  • Import-Mode-Preset attribute didn't work for Mode Disabling Dependencies and port related triggers in the 'keep' use-case
  • Save workspace in DCF format didn't work if BSWMD files with command line macros are specified in the ECU-Project
  • OS Application dialog crashed on editing an existing OS Application if more than one OS Application is defined for a task
  • A signal was treated as received through a frame although no rx relation existed. This results in an incorrect ECU-C synchronization because the signal was actually not used on Com layer
  • Rte generation was wrong because Rx signal relation was missing for Tx/Rx signals sent between two instances of a Multiple-ECU project
  • Calibration port init values were not correctly updated on ARXML import of existing software components
  • Graphic update was missing if 'complete delegation port' has been executed in a separate view
  • Data mapping was not imported/updated correctly in ARXML import of a Multiple-Ecu configuration with complex data types
  • Data mapping was lost on loading DCF workspace if not all data elements of a delegation port were connected to an atomic port prototype
  • USB dongle access caused GUI freeze in some situations

(top)


DaVinci Developer Version 3.0 (SP2)

Tool features

  • Support of AUROSAR schema version 3.1.4 and 3.0.6 in import/export and ECU-C synchronization
  • In addition to importing an ECU-Extract of System-Description the import of a System-Description containing more than one ECU is now supported by selecting the ECU to import
  • RTE measurement supported by specifying the according parameters at the Calibration Elements, Calibration Parameters, Inter-Runnable Variables, and in the global generation parameters
  • Specification of an Rx-Filter is now possible at the receiver communication specification
  • Minimum start interval can now be specified in the runnable properties
  • Double data mapping for a signal is now allowed if the Tx/Rx direction differs, i.e. the same signal can be used as sender and receiver

Usability enhancements

  • Newly created ECU projects using the DaVinci Project Assistant now contain default entries for generators/configurators
  • Automatic creation of server runnables can now be configured with an additional pre- or post-fix for the runnable name
  • New feature in the signal data-mapping editor to create ECU delegation port prototypes, which matches the Tx/Rx-Signals of an ECU project
  • ECU-C file synchronization no longer requires a specific AUTOSAR package structure
  • Graphic export to the Windows clipboard can now be initiated with Ctrl-G. Graphic file export now supports exporting of all Sheets in one step.

Fixed issues

  • Multiple instantiation of service components in the service mapping editor is now prevented
  • Wrong consistency check message about overflow in 64 bit data type range fixed
  • In some dialogs the edit controls were disabled instead of read-only which inhibits copying of the text content
  • Unexpected additional enumeration data type was created during ARXML import if COMPU-CONSTs exists for non-integer data-types
  • Missing consistency check for init values at the port's communication specification if two SWC receiving the same signal, but the port interfaces have different init values
  • Inconsistent rounding of imported values in DBC and ARXML with a precision of more than 15 digits fixed
  • Consistency check for different receiver invalid handling didn't work for external communication
  • Unexpected empty XML element <SD GID="edve:ValRef"></SD> was exported for calibration parameters without init value
  • Show reference in object usage dialogs didn't work if the object usage dialog was started on a object from within the search result list
  • Changing an ECU-Project's ECU-C-File does not always trigger an ECU-C sync if another tools hold an ECU-C lock
  • Updating an ECU-Project with a file that contains frames with equal (case-insensitive) SHORT-NAMEs had failed
  • Automatic ECU-C synchronization haven't detected generation parameter changes if the parameters were changed the second time
  • ECU-C file couldn't be found in DCF Utility because of using relative paths
  • ECU-Project settings couldn't be edited with DaVinci Project Assistant if the DPA file reference contains a relative path
  • Import ARXML from path containing Japanese characters failed
  • Parameters for Component Implementation Template Generation and Contract Phase Header Generation were mixed up in newly created ECU-Projects using the DaVinci Project Assistant
  • Too many ECU-C signals were created if PDU routing is designed when a frame is transmitted but not all signals have a tx relation
  • DaVinci crashed when a multi-selection of ECU-Projects is about to be exported to ARXML
  • DCF workspace couldn't be saved after modification if a Port-Prototype was deleted which was referenced by a Runnable's trigger
  • DaVinci crashed after deletion of the mode declaration group prototype with already used name
  • Compiler/Linker error due to inconsistent callback definitions for ports without port access but AliveTimout > 0
  • Tx callback was exported for Rx signal if the signal was sent and received on the same network
  • Task type was not correctly imported from ECU-C if different Os BSWMD contains a platform specific package
  • In rare cases update of an ECU-Project via XML import with ECU-Extract and ECU-C file failed with error message "Item already exists"
  • Importing an ECU-Extract using the Diff&Merge feature had corrupted the data mapping if additional signals or signal groups have been added
  • Service mapping was missing when exporting service layer components to ARXML or DCF
  • Record constants with invalid element order were created based on a Signal-Group
  • In some cases the error message "Receivers of the data element prototype <SignalName> handle the Rx-Filter on a different way." was reported even if the Rx-Filter were correctly defined.
  • Rte's Com-Callbacks for Signal-Groups use wrong Group-Signal identifiers if a Fan-In of Signal-Groups with mapping different frames of the same cluster exists
  • Generated Rte contains several callback functions with the same name if a signal is mapped to one pdu which in turn is mapped to several frames and the Rte has to generate a callback function for this signal

(top)


DaVinci Developer Version 3.0 (SP1)

Tool features

  • Support of LIN Signal-Groups defined LDF files with the naming convention <signal_group_name>__<signal_name>
  • AliveTimeOut is now imported from DBC and can be propagated using a new function in the data mapping view
  • The newly introduced automatic ECU-C synchronization during workspace load/save can be switched off in the global settings dialog
  • Display of calibration objects in the graphic can be switched off in the workspace settings
  • Support of ARXML import pre-configuration using generic attribute IMPORT_MODE_PRESET
  • Constant property "Generate Symbol" can now be set in Library-Browser via multi-selection

Fixed issues

  • Wrong workspace conversion that causes missing Signal Group references during ECU-C synchronization has been fixed
  • Inconsistent connections (wrong sender/receiver direction) were not detected by a consistency check
  • Error message in the GUI when changing R-Port's "Handle Invalid" property has been fixed
  • Compatibility settings couldn't be set properly in the workspace settings dialog
  • DCF Utility didn't show Activation Offsets in the ECU-Project binary file
  • Missing check messages on inconsistent data mappings have been added
  • Additional name information for "DEFINITION-REF" objects in difference view have been added
  • Inconsistent structure of a complex constant compared to its data type have caused a generation error even if the constant was not actually generated.
  • Out-of-memory error message occurred in DCF Utility when opening large dcb files
  • Missing sorting of FIBEX-ELEMENT-REF in difference view has been fixed
  • Crash in DaVinci DEV has been fixed when switching to the ModeDelarationGroups in the properties view
  • Show in software design command for runnables in task mapping page didn't work.
  • Error Handling for ModeQueueLength '0' has been corrected
  • Within the data element prototype page the CreateNewDataType button didn't work
  • During ARXML import the renaming a child object didn't always work if the names only differ in character case
  • External tool command line parameters are changed back to default if no parameters are given in the dialog
  • The consistency check for Calibration Ports has been weaken to allow compatible interfaces that are not identical
  • ARXML import failed if existing objects only differ in character case from objects that were to be imported
  • Tool crashed when saving new SwBlockNeeds with a mirror PIM that had no data type
  • In read-only SWCs the implementation popup menus were not disabled and tool crashes if menu commands was executed
  • Tool slowed down after running several hours because of GUI resource leaks
  • Wrong setting of working folder in attached files dialog fixed that caused error message while opening generated attached SWC template file
  • Generated OSAlarm and OSEvents didn't match because the setting 'use shortnames > 32' was not consistently communicated to the RTE
  • Added multiple mapping of the same system signal on one frame to support the multiplexing use-case
  • Extended support for Tx/Rx split and signal overlay in the Multiple-ECU use-case
  • ARXML runnable import of Init-Trigger corrected if no other Trigger exists
  • Fixed error while synchronize structure of a complex constant in AUTOSAR export if the structure of the complex data type has been changed
  • Newly created graphic sheet names were not stored correctly in the workspace
  • ECU-C file data wasn't fully loaded during opening DCF workspace if the AUTOSAR schema versions have been different
  • Generic attribute definitions weren't loaded during opening DCF workspace if a corresponding generic attribute didn't exists at an AUTOSAR object
  • Missing error message while opening incompatible workspace with RTE Generator fixed
  • Generation of templates and contract headers is now allowed for service components
  • Sorting of error/warning/info icons in the messages tab has been corrected
  • The initial graphic scroll-bar position was often not correct
  • Newly created Port-Prototypes are now automatically positioned near the original port
  • Auto-mapping for wasn't working well with multi instance SWC
  • Directory placeholders with workspace variables were not working correctly for DCF workspaces
  • Service mapping was missing when exporting service layer components to ARXML or DCF
  • Property dialog for NvM block needs threw an error when using read-only Component-Types
  • Some issues in workspace merger functionality have been fixed concerning communication merge, generic attributes, and data-mapping
  • The global attribute definition file in a DCF workspace can now be modified in the DCF-file to share it among DCF workspaces
  • The Mode disabling dependencies for runnable triggers were doubled during the XML import
  • Task attributes priority / description / schedule were incorrectly loaded from DCF workspaces
  • Signal bit length was not updated from DBC file if the signal with data-type reverence already exists
  • Service needs were deleted during special diagnostic import
  • Bad performance while switching from structure design to port prototype view solved by specifiying the livst view as default editor for non-graphic use-cases
  • ECU-C sychronize of Init Values produced unnecessary warning output
  • Init value check for the Data Mapping didn't work
  • Incorrect Exclusive Area Access after DCF loading if AR 2.1 SWC are used together with AR 3.0 ECU-C file
  • Attribute definition inconsistencies weren't reported during DCF loading
  • Inconsistent NvM block and PDAV order was not reported by a check
  • Signal's unit was not imported via LDF file
  • Crash has been fixed while opening ECU Project Software Design editor after large SWC was updated by importing new SWC definition
  • Loading of global generic attribute definitions has been restructured to avoid overwriting with local attribute definition during DCF loading
  • Wrong consistency message concerning maximum values was displayed due to rounding problems in physical value calculation
  • Workspace settings were reset on saving a DCF workspace as DEV
  • Read-only ECU-Projects were missing after loading a DEV workspace which was created out of an DCF workspace
  • Crash during DCF save has been fixed if many read-only DCF files are about to be stored
  • Signal length was set to null after a LDF file has been updated through the ECU-Project signal list
  • Data mapping was missing after loading DCF workspace if atomic software components were multiply instantiated within an ECU-Project
  • Update icon was not correctly displayed in Attached-Files dialog
  • In rare cases DCF save aborted with COM Error 0x80070057 if the ECU-Project contains a large amount of Software Component Prototypes

(top)


DaVinci Developer Version 3.0

GUI rework

  • New window concept for parallel editing in several views of an ECU project
  • Modernized GUI style, icons and tool buttons
  • Reworked library browser with additional folders for service related objects
  • Reworked software design views to enable multi-editing of object properties
  • Clear separation of global user settings and workspace specific settings
  • Changed workspace file extension (.dev)

Improved cooperation with DaVinci Configurator Pro

  • Project Assistant for convenient creation and update of ECU projects
  • Overwrite protection against ECU-C editing conflicts by mutual blocking of the tools

Usability enhancements

  • Drag&Drop of component types and port interfaces into structure graphics
  • Direct invocation of template/header generation for individual component types from context menu
  • More intuitive display of consistency check messages
  • Optional display of calibration ports and connectors in structure graphics
  • Display of additional info in data mapping editor for fan-in/fan-out signals
  • Improved object selection dialogs (display of additional info, enhanced filter logic)

Graphic design improvement

  • New layout function: Automatic positioning of delegation ports near the connected port
  • New layout function: Vertical/horizontal alignment of components
  • More intuitive zoom control via zoom-in/zoom-out buttons
  • "Align spread/packed" function available for a selection of ports

Performance enhancements

  • Speed-up of ECU-C synchronization
  • Speed-up of general XML import/export and consistency check

Merging of design data

  • Detailed merge control during import via difference view: overwrite workspace object or keep it
  • Fine-grained merge control for complete library objects or individually for each sub-object, e.g. runnable entities and port prototypes
  • Merge control setting persistently stored at each object - convenience for subsequent import

Tool features

  • Definition of service needs of component types
  • Support of complex device driver component types
  • Support of LIN signal groups in imported ECU Extract
  • Configurable symbol generation of constants
  • Definition of limits for calibration element prototypes
  • Support of unconnected R-ports and unconnected ports of calibration components
  • Definition of alive timeout at delegation port prototypes
  • Explicit trigger type "Init Runnable"
  • Definition of task type (basic/extended/automatic)
  • Definition of task role (application/BSW Scheduler/non-RTE)
  • Disabling of automatic trigger generation in the OS
  • Search function to find unused objects in the workspace
  • Support of invalid values within the range of 0 ... 255 for boolean data-type
  • Command line extension for DCF Utility to directly start a DCF workspace difference analyzing from the command line by specifying the 2 workspaces

Fixed issues

  • Recent file list was too small
  • Under rare circumstances copying of a software component caused a crash because of wrong graphic stream duplication
  • Overlay of component prototypes in the Multiple-ECU use-case is now based on the component type reference
  • During ECU-C synchronization the task activation value was not considered
  • If the first ECU-C synchronization has been done with the direction from ECU-Project into ECU-C file existing COM-Signals were duplicated in the ECU-C file
  • In some dialogs the display of the description contained non-printable line-feed characters
  • When saving a DCF workspace as DVW all read-only objects were skipped and thus were missing in the resulting DVW workspace
  • AUTOSAR export of NvRamAllocation was wrong when using AUTOSAR 2.1 format
  • The AUTOSAR import didn't correctly update existing ModeDeclarationGroupPrototypes
  • The minimal graphic canvas size couldn't be set using the specific dialog
  • Missing GUI update after modification of NvM blocks corrected
  • The description attribute of enumerators wasn't imported from the AUTOSAR XML
  • In some cases the message output of external generators was truncated in the log window display
  • Wrong command line parameter usage while starting external generators if a path parameter ends with a backslash
  • Truncated display of constant names in record type combo-box fixed
  • When using a constant to initialize a SWC local Calibration Parameter the according constant definition didn't appear within the exported AUTOSAR XML
  • The check messages tab content was not cleared on closing the workspace
  • Workspace was set to modified during ECU-C synchronization even if no modifications have been made
  • Limitation in number of tabs in the software design window has been increased from 32 to 100
  • Endlessly reappearing warning box when adding a calibration parameter with a name that already exists in the calibration parameter list fixed
  • ECU-C difference dialog has displayed boolean values as 0/-1 instead of false/true
  • Update of Task Mapping View was missing when a new runnable trigger with a so far unused cycle time was added

(top)


DaVinci Tool Suite Version 2.3 (SP7)

DaVinci Difference Analyzer

  • Display of semantical differences between AUTOSAR XML files
  • Supports System Description Files, SWC Description Files and ECU-C Files
  • Integrated into Windows Explorer context menu for files with extension .arxml
  • Integrated into DaVinci Developer: show differences before importing AUTOSAR XML files

DaVinci DCF Utility

  • List the associated files of a DCF workspace
  • Show the differences between two DCF workspaces
  • Find missing files in DCF workspace
  • View the content of DCB files

Usability enhancements

  • Task mapping: improved trigger view
  • Task Mapping: new view "Component View" to show the runnables per component
  • Service Mapping: new views "Service Component View" and "Application Component View"

Tool features

  • Design support for automatic creation of service ports and server runnables
  • Automatic synchronization of ECU-C file when opening and closing an external configurator
  • Detailed report of changed ECU-C settings during synchronization of ECU-C file
  • Unified display of consistency errors and RTE generation errors
  • Definition of scalings for enumeration types
  • Definition semantical limits for data element prototypes
  • Configuration of "switch only" and "ack only" access of mode P-ports

Fixed issues

  • Wrong painting of property pages in runnable editor after resize
  • Missing error message in case of invalid constants of complex data types
  • Inter-Runnable-Variable Access-Mode was missing after ARXML import
  • Misleading info message in case of missing INTERNAL-BEHAVIOR
  • Sending the same signal on both FlexRay channels was falsely considered as signal Fan-Out
  • Consistency check result for connected homopolar ports within service mapping was missing
  • Missing reference on generic attribute table in DCF in case of adding attribute definitions without additional modifications
  • System-Signal init value compatibility check reported wrong warning due to imprecise floating point calculation
  • Frame-Node relations were not imported from ARXML for CAN and LIN Frames
  • OS-Application property of tasks and description for ECU-Project got lost in DCF format
  • Missing objects in AUTOSAR Export if started through multi-selection in Library Browser
  • Problems occurred with DCF path definitions using slash '/'
  • ECU-Project memory mapping view hasn't respected read-only attribute
  • Incorrect update behavior of Port-Prototype dialog if a different Port-Interface was selected
  • Ports are displayed overlapping when calling 'Arrange Ports | Align Packed'
  • Ports were missing in port selection dialog because of filtering for non-strict compatible ports
  • In the Properties views of port connectors, the source/destination data element prototypes were not sorted at all
  • In the Properties views of port interfaces/prototypes, the data element prototypes were sorted in fixed descending order
  • Moving a multi selection of input and output ports hasn't worked in the graphic display
  • Tx-/Rx- evaluation during ECU-C Synchronization was wrong if the same signal was mapped to multiple messages received by different ECUs
  • Faulty error message about incompatible data element to signal mapping in case of record data types
  • During DCF loading the file name of currently processed ARXML file wasn't displayed
  • Creeping performance of code generation and ECU-C Synchronization due to wrong evaluation of task mapping references fixed
  • Wrong update of complex constants during ARXML import fixed if structure of the complex data type has been modified
  • Wrong display of IOHWAbstraction in Service Mapping tab fixed
  • COM-Error code while loading DCF workspace with parameter group generic attributes fixed
  • Wrong Task-Priority value during ECU-C Synchronization on Asian Windows fixed
  • Further performance enhancement during ECU-C Synchronization and Rte generation
  • Missing consistency check for received Data-Elements
  • AUTOSAR XML import containing a CompuMethod with Factor = 0 causes endless loop

(top)


DaVinci Tool Suite Version 2.3 (SP6)

Tool features

  • Enhanced generator selection for ECU-Projects with support of RTE Generators in different versions
  • Additional option whether string data types will use a terminating NULL-byte
  • Support of open P-Ports
  • Support of signal fan-in use case in ECU Configuration
  • Enhanced auto-mapping rules for memory-mapping
  • Support of AUTOSAR component type "ECU Abstraction" for desinging IoHwAbstraction
  • Definition of communication specification at composition ports
  • Various GUI round-ups and enhanced consistency checking

XML Import/Export

  • Enhanced workflows:
    • Special overwrite of port prototypes incl. communication specification during import
    • Component implementation merge dialog during import
    • Optional export of top-level structure only
    • User notification in case the ECU-C file has been modified by another tool
  • Enumeration constants are now stored with their numeric value as defined in AUTOSAR
  • Import of communication data (e.g. signals) is now case-insensitive, i.e. signal names cannot be different in character case only
  • Support of explicit rx/tx relation for FlexRay PDUs
  • Opaque value can now be stored with byte representation as defined in AUTOSAR specification
  • Enhanced sorting of elements within exported ARXML files
  • MICROSAR standard service port interfaces are now available as AUTOSAR import file: <DaVinci>\Data\ServicePortInterfaces.arxml

Fixed issues

  • Signal invalid values were not displayed as physical value
  • Some FlexRay cluster attributes were missing in AUTOSAR export
  • Invalid values for 32 bit opaque data types couldn't be defined
  • Generic attributes were missing at the Calibration Parameter when stored in DCF format
  • Crash in AUTOSAR import fixed if file contains a ModeDeclarationGroup without a valid reference to an initial mode
  • Error during AUTOSAR export if both export options 'Export user-defined attributes' and 'Create data types/constants for signals if required' are checked
  • Crash fixed when opening large amount (>70) of Component Type editors simultaneously
  • Wrong import of extended CAN identifiers fixed
  • Missing DCF update added to avoid that deleted objects re-appear after DCF loading
  • Wrong renaming if new name only differs in character case
  • Memory leak fixed when importing large amount of data
  • Application blocking of DaVinci / MICROSAR RTE fixed when working on the same workspace

(top)


DaVinci Tool Suite Version 2.3 (SP5)

Support of Mode Management

  • Design of Mode Declaration Groups and Mode Port Prototypes
  • Runnable trigger on Mode Entry, Mode Exit, Mode Switch Acknowledge
  • Definition of Mode Disabling Dependencies for all runnable triggers

Further port and runnable trigger enhancements

  • Support of data element invalidation
  • Support of Data Reception Error trigger in case of Rx Timeout

Tool features

  • Enhanced GUI and consistency checking for mode / trigger / port access definition
  • Automatic mapping of service ports according to naming conventions
  • Enhanced automatic data mapping for complex data types
  • New consistency check to report inter runnable variables using string data-types
  • Support for recursive connections (connection between ports of the same component) within an ECU SW-Composition.
  • Selective diagnostics import depending on PDM-ID attribute

XML Import/Export

  • Support of AUTOSAR schema 3.0.2 with DCF import/export
  • Support of FlexRay ISO TP in AUTOSAR System-Description
  • Temporary workspace is no longer required for DCF import/export

Fixed issues

  • Data type was missing in DCF export if referenced by a port defined argument value
  • Unable to adapt the signal data type according to the data mapping if the init value was missing
  • Predefined data types were missing in initially created DCF workspace
  • ARXML import of cycle time causes a value overflow if the decimal precision exceeds 15 digits
  • Existing service mapping is no longer overwritten on importing an ECU-Extract
  • Incompatible Factor, Offset, Unit was not reported by data-mapping compatibility check
  • Closing the application is no longer possible while DCF saving is in progress

(top)


DaVinci Tool Suite Version 2.3 (SP4)

Support of RTE Memory Protection in DaVinci DEV

  • Definition of OS application (trusted/untrusted)
  • Assignment of tasks to OS applications

Extended consistency check

  • Allow split and merge of connectors in SW design
  • Tolerant data mapping of complex data types
  • Flexible data mapping for string types (signal length 1 byte smaller than the string type is now allowed)

Usability enhancements

  • Signal Routing in DaVinci SAR: Automatic signal routing now possible for individual signals
  • Signal Routing in DaVinci SAR: A correct routing path is now skipped by automatic signal routing
  • No more reset of global tool settings after installing a new DaVinci version

XML Import/Export

  • Improved handling of BSWMD files during ECU-C synchronization
  • Import/Export of COM-PROCESSING-PERIOD
  • For LIN import the cluster protocol version is used for the slaves if their protocol is not set

Fixed issues

  • Missing data mapping in DCF format
  • String constant values don't support full character set of ISO-8859-1
  • P-/R-port connector list views display duplicate components
  • Obsolete check messages in the output window
  • Update problems in structure graphics
  • Memory leak while saving DCF workspace removed
  • Endless loop on data-mapping of complex data-types fixed
  • Scaling of signal/data-types has not been considered correctly in data-mapping compatibility check
  • LIN diagnostics frames will now be automatically created in DaVinci Network Designer if they are not available
  • Port-Interfaces were always updated during DCF saving even if no modifications have been made
  • ECU-C file path is now adapted on workspace Save-As and is only written on ECU-C relevant modifications
  • Different generation check results were occurred depending on the generation start method by popup-menu or generator-list
  • Endless loop while opening a read-only Component-Type graphic fixed

(top)


DaVinci Tool Suite Version 2.3 (SP3)

Port API options

  • Option "Enable Indirect API"
  • Option "Enable API usage by address"

Miscellaneous

  • Consistency warning in case of runnable entities with period 0 (except for init runnables)
  • User-defined attributes for Task and ECU-Project
  • ARXML import: Support of FlexRay frames sent by different ECUs in the same slot
  • ARXML export: Support of LIN2.0 specific communication properties in ARXML 3.0
  • DVImEx.exe command line utility is now able to import/export ARXML files based on DCF workspace

Fixed issues

  • Copy&paste by keyboard shortcuts not supported in "Implementation" page of Component Type Editor
  • Data mapping displays signal groups, which don't belong to the ECU project
  • Problems in "Data Mapping" and "Service Mapping" page in case of multi-instantiated components on different hierarchy levels
  • ECU-C Sync: ComTimeoutNotificationCallback for AliveTimeout generated in wrong format (AR2.1 instead of AR3.0)
  • Range check during XML import fails in case of 64 bit signals
  • Constant- and Signal-Dialog displays wrong values in case of 64 bit data-types/signals
  • Automatic data mapping ignores child elements of composite data types
  • Consistency check does not report duplicated component prototype names
  • ARXML export: T2 values from dbc ignored when generating IPDUTiming
  • ARXML export: typo in generated XML file in case of infinite limit of real data types
  • ARXML import: problems with upper/lower case of short names during import of service components
  • Frame mapped signal group information can't be stored in DCF
  • ECU-C synchronization fails if BSWMD files are specified with path information

(top)


DaVinci Tool Suite Version 2.3 (SP2)

Miscellaneous

  • Multiple instantiation of atomic component types on the same ECU is possible now
  • Specification of RTE Compatibility mode API at the software component
  • Full AUTOSAR support of Signals with Data-Type definition and initial value constant; Legacy Signal-Type support has been removed from DaVinci SAR
  • Auto-Data-Mapping now support complex data-types that will be mapped on signal groups
  • Enhanced performance during workspace saving if many data-types or constants exists

AUTOSAR XML Import/Export

  • Support of officially released new AUTOSAR schema version 3.0 rev. 3
  • It is now allowed to work with ECU-C and BSWMD files having different AUTOSAR patch-versions
  • ARXML export has duplicated the sender-receiver mapping on R-Ports
  • ECU-C synchronization is now only done for elements if the ECU-C does contain a corresponding module configuration
  • SwComponentInstances for Calprm-ComponentPrototypes are no longer exported in ECU-C file

Fixed issues

  • Under some circumstances the data-mapping compatibility check was running into an endless loop for complex data types
  • Wrong ranges are displayed for 64 bit data types / signals in DaVinci SAR/DEV
  • Some memory leaks during ECU-C file synchronization have been fixed
  • In the ECU-Project data-mapping the Tx-Signal Groups were missing for local ECU communication

Known issues

  • AUTOSAR export will fail if the two options "Export user-define attributes" and "Create data types/constants for signals if required" are enabled both. Workaround: start the export two times with only one option enabled.

(top)


DaVinci Tool Suite Version 2.3 (SP1)

Miscellaneous

  • List view for non-graphical display of compositions
  • Support of range enumerators in enum types
  • Configurable consistency check for initial value of data element and mapped signal

XML Import/Export

  • Import/Export of FlexRay PDUs in AUTOSAR 3.0 XML

Fixed issues

  • DCF storage
    • DCF read-only error response doesn't work for port interfaces
    • Saving DCF does overwrite read-only files
    • Sheet names not stored in DCF
    • ECU-Project local signal attributes were not stored in DCF
    • Storage of unmapped Network-Signals in DCF added
  • ARXML Import/Export
    • Invalid value is not being imported with ARXML 3.0.1
    • Wrong import of signal unit attribute fixed
    • Fixed import for runnable wait points on asynchronous server calls where the runnable doesn't access the server itself
    • Import crashes if Data-Types doesn't contain min/max ranges
    • Import crashes if timeout of synchronous server call point is missing
    • Generic attributes were missing for Network-Signals
    • More detailed error-message if the AUTOSAR schema version is not supported
    • Fixed import of Network-Signal's init value if referenced constant is of type enumeration
    • Missing import of signal's min/max values / value-type added if a data-type is referenced
    • Some FlexRay node parameters were missing in import/export
    • ECU-C file is no longer re-sorted after export because element order has to be obtained
  • DaVinci swaps min and max values for data types with huge range
  • ECU-C synchronize for Os/Com/Nvm now possible even if Rte is in sync
  • Signals and Data-Type scaling calculation fixed for negative factors greater than -1.0
  • Automatic data-mapping has falsely used signals from signal-groups for primitive data elements
  • Crash in creation of NVM-Blocks if the name was already used by another NVM-Block
  • Incorrect signal-routing in DaVinci SAR fixed if signals are defined in more than one global signal group
  • Check of array data-types hasn't report an array size 0 correctly

(top)


DaVinci Tool Suite Version 2.3

XML Import/Export

  • Import/Export of component descriptions, communication descriptions, and ECU-C via AUTOSAR 3.0 XML (XSD rev. 0001 and rev. 0002)
  • Preliminary FlexRay PDU support: conversion of PDUs into signal groups during import of AUTOSAR 3.0 XML (FIBEX 2.0 compatibility)

Calibration parameters for components

  • New page "Calibration Parameters" in component type editor
  • Assignment of parameter groups via user defined attribute (enum attribute definition "PAR_GROUP_CAL" with arbitrary group names as enum values)

Calibration component types

  • Definition of calibration component types (new realization type "Calibration")
  • Definition of calibration port interfaces and calibration port prototypes
  • Referencing and connecting of calibration components within a composition type

Per-instance memory

  • Definition of per-instance memory of a component type
  • New page "Memory Mapping" in ECU project editor to map per-instance memory to NV memory blocks (DEV only)
  • Manual and automatic definition of NV memory blocks (DEV only)
  • Export and synchronization of NvM section in ECU-C file (DEV only; not available in AUTOSAR 3.0 XML)
  • BSWMD file for NvM module configurable for an ECU project (DEV only)

MICROSAR RTE Configurator

  • New exe in bin folder: DVRteConfig.exe
  • Configures the MICROSAR RTE (Task Mapping, Memory Mapping, Generation Parameters)
  • Operates directly on AUTOSAR XML (ECU Extract of System Description plus associated ECU-C)
  • Same RTE configuration functionality as DaVinci DEV. Not required, if DaVinci DEV is used.

DaVinci Configuration Files (DCF)

  • DCF: Alternative storage format for DaVinci workspaces
  • Support for file-based configuration management of DaVinci design data
  • New user manual: UserManual_Working_with_DCF.pdf

Miscellaneous

  • Support of asynchronous C/S communication
  • Support of string data types (data types larger than 8 bytes)
  • Support of explicit gateway routing in DaVinci SAR: data mapping of connected data elements to different signals supported
  • Import of user-defined attributes via DaVinci attribute XML format
  • Selection of both FlexRay channels (redundant transmission) possible in the "Signal Routing" page of DaVinci SAR
  • Performance enhancement of Data-Mapping editor in DaVinci SAR

Fixed issues

  • Missing update of VFB Tracing page after calling ECU-C synchronization
  • In rare cases RTE generation can't be initiated due to model inconsistencies even if ECU project check succeeds
  • Usage of atomic component type as top-level component of a Vehicle-Project is now checked and reported

(top)


DaVinci Tool Suite Version 2.2 (SP4)

Usability enhancements in graphical editors

  • Display of mapping info in Function Design page of Vehicle Project Editor (SAR only)
  • Automatic creation of delegation ports
  • Change of port prototype alignment by Drag&Drop
  • Automatic arrangement of port prototypes: alphabetically, connected/unconnected
  • Copy&paste of port prototypes
  • Re-connecting of connector prototypes (change the start or end port)
  • Better visibility of selected objects in graphical editors
  • Zooming with <Ctrl> + mouse wheel or with +/- keys
  • Object positioning with arrow keys

Miscellaneous usability enhancements

  • List view in ECU mapping page (SAR only)
  • Display of additional context info in ECU Pin Mapping (SAR only)
  • Wildcards supported in Object Selection Dialog
  • Display of connectors in Object Usage Dialog

Editable network topology graphics (SAR only)

  • Manual layout mode and automatic layout mode selectable
  • Manual placing of ECUs and networks
  • Drawing of networks via line segments

Automatic data mapping

  • Automatic selection of signals for unmapped data elements
  • Selection based on best guess name matching
  • Adaptation of automatically created data mappings possible

Miscellaneous

  • Connector Tracing Dialog for function design (SAR only)
  • Extended consistency check (open ports, unmapped components, incompatibility in case of queued/unqueued data elements)
  • Support of XML schema of AUTOSAR Release 2.1.4 (XSD rev. 0018)
  • Update of AUTOSAR Release 2.0 XML schema export: service mapping, scaled data types with shared base types
  • Relative paths of BSWMD files supported (DEV only)
  • XML export for AUTOSAR Release 1.0 DTD not supported any more

Fixed issues

  • Error message when trying to open properties dialog of a C/S connector
  • Crash when importing a "double" data type
  • Wrong check message about multiple runnable triggers
  • AUTOSAR XML Import/Export of C/S communication specification was not supported
  • Consistency check for enum constant values was missing

(top)


DaVinci Tool Suite Version 2.2 (SP3)

RTE features

  • Support of complex hierarchical data types like arrays-of-records
  • Convenient configuration of VFB tracing by import of trace functions from Rte_Hook.h

XML Import/Export

  • Support of short names with 128 characters (tool option)

Enhanced consistency checks

  • Detailed consistency check and data re-synchronization now available in DaVinci SAR
  • Messages page in output window now available in DaVinci SAR
  • Consistency check for individual component types supported

Usability enhancement

  • Automatic creation of delegation ports to support bottom-up design
  • Smart template generator with update functionality now available in the attached file list of a component
  • Definition of a global output path in DaVinci DEV

Miscellaneous

  • AUTOSAR 1.0 XML format not supported any more

Fixed issues

  • Import of TargetLink-generated XML files fails in some situations
  • Crash in case of incomplete imported data (missing data type reference of data element prototype)
  • Default values of Generation Parameters page do not appear correctly in ECU Configuration File
  • Duplicate DATA-SEND-COMPLETED-EVENTs in XML export in some situations

Known issues

  • Old tool versions until V2.2.44 (SP2) crash without error message when trying to open a workspace, which has been created with V2.2 SP3
  • Task mapping of service components cannot be imported from ECU Configuration File

(top)


DaVinci Tool Suite Version 2.2 (SP2)

Support of AUTOSAR release 2.1

  • XML Import/Export according to AUTOSAR 2.1 schema
  • Adaptation of object properties according to AUTOSAR 2.1
  • RTE generation according to AUTOSAR 2.1

Service mapping

Support of AUTOSAR 2.1 concept of service components and service connectors in DaVinci DEV

  • List view in Component Type Editor for non-graphical defining of service ports
  • Definition and import of service Component Types
  • New page "Service Mapping" in ECU Project Editor to create service connectors

RTE features

  • Generation of RTE memory usage report
  • Adaptation of object properties according to AUTOSAR 2.1
  • Support of activation offset for cyclic runnable entities
  • Support of AUTOSAR compiler abstraction and memory abstraction mechanism
  • Support of AUTOSAR makefile mechanism for the RTE
  • Additional APIs supported: Rte_InitMemory, Rte_IWriteRef
  • Smart template generator: Update of component implementation files after changing component description
  • Summary of generated files displayed in output window

XML Import/Export

  • Export of scalings into separate package
  • Export of various additional tags to support Elektrobit Tresos
  • Additional consistency checks during import

Miscellaneous

  • Demo workspace "InteriorLight" extended by a ComManager service component
  • Reload workspace functionality moved from view menu to file menu with (Ctrl+F5) shortcut

Fixed issues

  • Rte_Feedback returns illegal error codes in some conditions
  • Generation of multiple internal S/R buffers (unqueued communication) with identical name
  • Rounding problems with 64 bit signals
  • Multiple buffers generated for buffered Interrunnable Variables
  • DaVinci SAR: Derivation of software architecture fails if function net contains empty connectors

(top)


DaVinci Tool Suite Version 2.2 (SP1)

RTE features

  • Support of Port Defined Arguments (XML import and RTE generation)

Fixed issues

  • Import of enumerator names with more than 32 characters not possible
  • Data Mapping on FlexRay: Same signal displayed several times in selection dialog
  • Application errors of C/S port interfaces not considered in consistency check
  • Record constants missing in contract phase header

(top)


DaVinci Tool Suite Version 2.2

DaVinci DEV as standalone tool

  • Full-featured design of application components possible with DaVinci DEV
  • Setup of ECU projects without vehicle project possible
  • Signal import via DBC, FIBEX or LDF files
  • Separate command line generation tool for RTE generation: DVRTEGen.exe
  • Detailed consistency check of ECU projects (Messages page in output window)

AUTOSAR compliant ECU configuration with DaVinci DEV

  • Storage of RTE configuration as AUTOSAR ECU Configuration File
  • Synchronization of DaVinci workspace with a given ECU Configuration file possible
  • Configurable list of external configuration tools for cooperative editing of the ECU Configuration File
  • Obsolete concept of DaVinci Target Packages eliminated. Automatic building of CANoe target DLLs suspended.

RTE features

  • Support of array types and enumeration types
  • Support of exclusive areas and inter-runnable variables
  • Definition of data-send-completed trigger
  • State request API for data send points
  • Detailed configuration of VFB tracing
  • Support of symbol attribute of runnable entities

XML Import/Export

  • Merge functionality during XML import to support iterative development processes
  • Support of XML schema of AUTOSAR Release 2.0 SP3

Fixed issues

  • Task mapping in ECU Configuration file should base on RTE event references instead of runnable entity references
  • Definition of communication specifications should be only possible at assembly port prototypes
  • Derived port prototypes are not incrementally updated when changing the function network
  • Some element issues in XML export (missing data type at operation arguments, wrong number format)
  • Inconsistent event configuration when server and all client runnables are mapped to same task
  • Missing read-modify-write protection for queue overflow flags

(top)


DaVinci Tool Suite Version 2.1 PRE (SP3)

Software Design

  • Software design editor for ECU software architecture
  • Redefinition of the top-level granularity of the ECU's software architecture
    see 'DaVinci_DEV_ECU_SW_Design.pdf' in DaVinci Documentation Browser for detailed description
  • Support of user-defined ECU-Project local ComponentPrototypes
    see 'DaVinci_DEV_ECU_SW_Design.pdf' in DaVinci Documentation Browser for detailed description
  • Definition of 'Not Valid Value' and 'Initial Value' (physical) at the signal added.
  • Definition of 'Invalid Value' at the DataType added. The specification of an 'Invalid Value' creates a DataType with semantic
  • Definition of a receive timeout value at the input function port added.

XML Import/Export

  • Import/Export of INVALID_VALUE definition according to AUTOSAR 2.0 schema

Fixed issues

  • Editors remain open after deletion of corresponding context item.
  • Inconsistent display of data mapping connectivity information.
  • Internal connections between multi-instantiated SWCs are not correctly detected in DaVinci DEV.
  • Function Design editor view is not updated when adding a new function.
  • Incorrect conversion of component graphic block.
  • Incorrect alignment of Function-Net derived composition types.

(top)


DaVinci Tool Suite Version 2.1 PRE (SP2)

XML Export

  • Additional export of user-defined attributes in a separate AUTOSAR XML file
    see 'TechnicalReference_UserDefinedAttributeExport.pdf' in DaVinci Documentation Browser

(top)


DaVinci Tool Suite Version 2.1 PRE (SP1)

Software Design

  • Refinement of existing software architecture within DaVinci DEV
  • Editable runnables and generic attributes in derived software architecture

Client/Server communication

  • Support of serialized C/S communication with support of AUTOSAR attribute "Can be invoked concurrently"
  • Trigger sorted view for operation invokation trigger in task mapping editor
  • Derivation of operation invocation trigger from function trigger specification

ECU Configuration XML export (only DaVinci Developer)

  • Export of RTE requirements to Com configuration (ComNotifications)
  • Export of RTE requirements to Os configuration completed (OsAlarms, OsEvents)
  • Configurable definitions for Com module and Os module in generated XML file

Fixed issues

  • Crash when opening runnables properties dialog in task mapping editor
  • Bad performance in large function net designs
  • Wrong update of derived software architecture if function ports have been changed
  • Automatic signal routing was not available for complex data types with signal groups

(top)


DaVinci Tool Suite Version 2.1 PRE

Client/Server communication

  • Definition of C/S Port Interfaces and C/S Port Prototypes
  • Selection of Operation Invoked trigger

XML Import

  • Import of XML files according to AUTOSAR 2.0 schema
  • Multi-file import context supported
  • Workspace consistency guaranteed by pre-import check of XML files

Enhanced usability of graphical editors

  • Component Type Editor for direct editing of component types without vehicle project
  • Port alignment may be defined individually for each component prototype
  • Direct editing of port prototypes within the structure view
  • Function Editor for direct editing of functions without vehicle project

AUTOSAR 2.0 compatibility

  • Multiple triggers per runnable entity supported
  • XML export for AUTOSAR 2.0 schema available

XML Export of RTE configuration (only DaVinci Developer)

  • Export of RTE configuration as AUTOSAR ECU Configuration Description file

Code Generation (only DaVinci Developer)

  • Separate generation step for AUTOSAR RTE
  • RTE generation possible without installation of a DaVinci Target Package

Fixed issues

  • Navigation between sheets via cross reference symbols not possible
  • Mapping view table not displayed any more in some situations
  • Constants not considered in compatibility check of record data types
  • Misc. issues in XML export (wrong TREFs, empty CONSTANTS tag)
  • Port prototypes of a component type not displayed in Object Usage Dialog
  • Connectivity status not correctly updated in GUI

(top)


DaVinci Tool Suite Version 2.0 PRE (SP3)

Graphical Topology Editor

  • Network topology can be graphically displayed in the context of a vehicle project. The graphic is calculated on demand and can't be modified. The topology objects can be selected in the graphic and edited through the objects dialogs

Modeling of devices

  • Devices with electrical properties can be globally defined in the Library-Browser and assigned to pins of an ECU.
  • Device Accessors within a Function Net can be mapped to concrete devices connected to the ECU pins.
  • The ECU Pin Topology is graphically displayed in the ECU Topology Editor accessible through the ECU in the Vehicle Project.

Support for complex data types

  • Data types can be defined as record containing any number of non-record data types as record-elements
  • Data mapping is done through signal groups where each record-element has to be mapped to a compatible signal within the signal group

Support for simple data semantics

  • Simple data semantics consisting of scaling information (factor, offset, unit) can be specified at integer and real data types. This information is exported as PRIMITIVE-TYPE-WITH-SEMANTICS in the AUTOSAR XML Export
  • Scaling is relevant for data mapping, i.e. a scaled data type requires a scaled signal to be compatible

Support for Waitpoints

  • Additional "Data Access" tab page in the component type dialog to specify the access mode for Queued (Polling, Waiting) and Non-Queued (Direct, Buffered) communication

AUTOSAR Code-Generation (only DaVinci Developer)

  • Basic Software Modules updated to AUTOSAR 2.0 API specification. Existent software component code based on previous AUTOSAR specification has to be adapted to new API.
  • Support of V850 Real-Target with GreenHills 4.0.7
  • Support of M32C Real-Target with IAR 3.10

Fixed issues

  • Data-mapping calculates wrong bit-length for some data type ranges
  • Deletion of component prototypes referencing multiple instantiated component types may corrupt task mapping
  • Completion of Device Accessors within Function Net was sometimes wrong
  • MATLAB/Simulink support of signal groups was not working correctly
  • MATLAB/Simulink import does not attach the behavior model to the function

(top)


DaVinci Tool Suite Version 2.0 PRE (SP2)

AUTOSAR Code-Generation (only DaVinci Developer)

  • Support of V850 Real-Target with GreenHills 3.51

Support for direct / buffered communication

  • The access mode to the data element prototypes can be specified for each runnable entity.
    • None: The runnable doesn't access a specific data element prototype.
    • Direct: The runnable explicitly accesses a specific data element prototype. The RTE generation uses direct API calls without additional buffering.
    • Buffered: The runnable implicitly accesses a specific data element prototype. The RTE generation will use additional buffering to keep the state unchanged during runnable execution.

Performance enhancements

  • Management of workspaces with huge amount of signals has been improved
  • Faster display of tree objects in Project-Explorer and Library-Browser

Configuration management suspended

  • Due to some internal restructuring issues the configuration management support has been temporarily disabled. It will be re-activated in one of next releases.

Fixed issues

  • Various AUTOSR XML Export issues fixed
    • ENTRY-POINT is now generated for the IMPLEMENTATION
    • Ambiguous NUMERIC-CONSTANT if the same Data-Type is used in different ports at the Component-Type
    • Description for constants were missing
  • Copy/Paste of Network within the same Vehicle-Project may crash
  • Update of Signal-Routing was incorrect under some circumstances, e.g. deleting a Network
  • Data-Type ranges for real-single and real-double corrected if -INF or +INF are used
  • Data-mapping creates signals with wrong bit-length

(top)


DaVinci Tool Suite Version 2.0 PRE (SP1)

AUTOSAR Code-Generation (only DaVinci Developer)

  • Integration of Vector AUTOSAR Evaluation Bundle with Code-Generation of AUTOSAR SW-Architecture for PC- and Real-Target
  • Support of CANoe PC-Target with Microsoft Visual C++ 6.0 / 7.1
  • Support of M32C Real-Target with Renesas 5.20

Task-Mapping extension for runnables

  • Each runnable entity defined at the Component can now be mapped to a task
  • Additional external tasks can be defined through attachment of OIL-Component files at the ECU-Project

Documentation

  • Documentation of AUTOSAR XML Export: See "DaVinci AUTOSAR XML Cross Reference" in the Documentation Browser
  • User manual of Tool concepts, AUTOSAR RTE and code-generation: See "Vector AUTOSAR Evaluation Bundle" in the Documentation Browser
  • Online-Help for DaVinci Network Designer CAN is now available
  • Online-Help for DaVinci System Architect and DaVinci Developer is currently not available

AUTOSAR XML Export

  • Option in export dialog to generate full-qualified short names
  • Export of IMPLEMENTATION with ENTRY-POINT

Fixed issues

  • Various AUTOSR XML Export issues fixed
    • Wrong format of P-PORT-PROTOTYPE-REF and R-PORT-PROTOTYPE-REF
    • Short name of TIMING-EVENT missing
    • Definition of BOOLEAN-CONSTANT with BOOLEAN-TYPE-TREF corrected
    • Deleted signals may cause artifacts in the element <SYSTEM-SIGNAL>
    • In some cases a DATA-RECEIVE-POINT was exported where a DATA-SEND-POINT was expected
    • A reference to a DataElementPrototype lacks the ComponentType; a reference to a RunnableEntity lacks the InternalBehavior
    • The values created for the tags CYCLE-TIME, CYCLE-TIME-REPEAT, STARTING-TIME, and DEBOUNCE-TIME are not correctly scaled to unit second
    • Sensor/Actuator creates an internal behavior using an ATOMIC-SOFTWARE-COMPONENT-TYPE-REF instead of a SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE-REF
    • Constants defined in the scope of a Data-Type were not exported
    • Object references using a “*” for fully dereferencing of the current context are valid definitions according to the "Template Formalization Guide", but may be difficult to interpret for XML-Importer. The creation of references with stereotype <<instanceRef>> have been changed by adding the name of a Port-Prototype in front of the qualified name: "port_prototype_short_name*/Element1"
  • Component-Prototype can only be created within Compositions. Trying to create it within other Component-Type was not inhibited and causes a crash.
  • ECU specific signal choice dialog causes crash in data mapping
  • Object can't be renamed to a name with different character case
  • Wrong behavior of radio-buttons within Data-Type dialog
  • Autorouting of signals doesn't recognize ambiguous receiver within one network correctly
  • Mapping of runnables causes deletion of network signals
  • Drag&Drop for Sensor/Actuator in mapping page was missing
  • Runnable name and description was not stored correctly
  • In some cases the function port update in function design structure graphic was missing
  • Crash in interface editor if port interface of an exiting port prototype was deleted
  • Wrong Tool-Tip behavior in trees consumes all mouse inputs on the subjacent item
  • Deletion of a ECU-Project within the Vehicle-Configuration causes a fully deletion of the ECU-Projects itself and not of the link

(top)


DaVinci Tool Suite Version 2.0 PRE

Prerelease to introduce the new tool concept and the AUTOSAR design support. Comprised tools:

  • DaVinci System Architect 2.0 PRE
  • DaVinci Developer 2.0 PRE
  • DaVinci Network Designer CAN 1.0 PRE

Support of Code Generation/Target Packages and ECU State Management is suspended.

New tool concept

Specialized tools for each design use case:

  • DaVinci System Architect: Specialized tool for system design
  • DaVinci Developer: Specialized tool for ECU code integration
  • DaVinci Network Designer: Specialized tool for network design

New tool framework

  • Common look-and-feel for all DaVinci tools
  • Introduction of projects (vehicle project or ECU project) as "working context"
  • New concept for editor windows

Function Design (only DaVinci System Architect)

  • Definition of functions with signal interfaces
  • Definition of device accessors for specifying signal interfaces of sensors and actuators
  • Function-local specification of signal properties allowed to support preliminary integration of a function net
  • Manual and automatic definition of function port connectors
  • Graphical visualization of function net consistency
  • Definition of hierarchical signal groups
  • User-defined stereotypes for signals and functions
  • Stereotypes are configurable through the STEREOTYPE.INI file located in the DaVinci Bin\Config directory
  • Optional display of stereotypes within function graphic
  • Function trigger definition (cyclic, spontaneous, on input signal)
  • Definition of function execution sequence
  • Derivation of a function net as an equivalent AUTOSAR SW architecture

AUTOSAR-compliant SW Design (only DaVinci System Architect)

  • Definition of data types
  • Definition of port interfaces with data element prototypes
  • Graphical design of atomic software components types and composition types
  • Definition of runnable entities
  • Trigger types "periodically" and "data reception" supported
  • Graphical design of SW structure by definition of component prototypes

Data Mapping (only DaVinci System Architect)

  • Mapping of network signals to data elements
  • Analysis of data element connectivity (internal vs. external communication)

ECU Mapping (only DaVinci System Architect)

  • Mapping of functions or components to ECUs
  • Definition of mapping constraints to ensure that all sub-functions/sub-components are located on the same ECU

Signal routing (only DaVinci System Architect)

  • Definition of signal routing paths within the vehicle topology
  • Signal routing across gateway ECUs supported

Export of AUTOSAR XML-files (only DaVinci System Architect)

Export of design data into the AUTOSAR XML-format (AUTOSAR 1.0, DTD revision 12342).

  • Export of complete vehicle projects with all sub-objects
  • Export of individual objects like data types, port interfaces or component types

User-defined stereotypes (only DaVinci System Architect)

  • Stereotypes are configurable by a STEREOTYPE.INI file located in the DaVinci Bin\Config directory
  • Stereotypes supported for functions, signals and signal groups

Import/Export of MATLAB/Simulink models (only DaVinci System Architect)

  • Import of Simulink models as function hierachy
  • Export of individual functions or complete function hierarchies as Simulink model
  • Import/Export includes signal groups and stereotype annotation
  • An example model "ImportExample.mdl" is available in the "Work"-Directory of the DaVinci installation
  • An example workspace "ImportExample.dvw" having imported "ImportExample.mdl" is available in the "Data"-Directory
  • Style guide for Simulink import is available in the DaVinci documentation browser

Network design (only DaVinci Network Designer)

  • Explicit definition of CAN messages and network signals
  • Definition of Tx- and Rx-relations
  • Definition of message layout with various display schemes
  • Manual or automatic definition of DLC
  • Display of gateway tables
  • Network timing analysis
  • Import/Export of DBC
  • Import of MDC files

Task mapping (only DaVinci Developer)

  • View modes for displaying the components in a flat list or sorted by trigger types

Object Usage Dialog (only DaVinci System Architect and DaVinci Developer)

  • Tracking of usage relations between objects in the workspace
  • Two tracking directions:
    • Referencing objects: Upward tracking (which objects use me)
    • Referenced objects: Downward tracking (which objects do I use)

Search Function (only DaVinci System Architect and DaVinci Developer)

  • Searching of objects by name
  • Search for specific object types

Limitations

  • Auto-mapper for network signals not available
  • Multi-instantiation only supported for atomic software component types, not for composition types
  • All runnable entities of a component are always mapped to the same task

(top)


DaVinci Tool Suite Version 1.0 (SP4)

Support of Microsoft Visual C++ 7.1

  • PC-Target generation using CANoe OSEK library is now available for Visual C++ 7.1 compiler, which is part of Microsoft .NET 2003 release. Legacy Visual C++ 6.0 is still supported.

CANdesc Basic Diagnostics for DB-Kom

  • Support for CANdesc Basic diagnostics using DBKOMgen Version 2.51
  • Extension of initial firmware generation for application callbacks
  • Attachment of generated diagnostic files
  • Notes concerning the generated template file "AppDesc.c":
    An application diagnostic template file "AppDesc.c" will be generated in the ECU output directory at each code generation. This file has to be initially attached once at the ECU to fulfill the diagnostic functions. It is highly recommended to use an ECU specific name rather than the standard "AppDesc.c". After attachment the file may be modified to code application specific diagnostic functionality.

Event Triggered Execution

  • In addition to the cyclic execution of software components, it is now possible to defined events to tigger execution of procedures at the behavior components.
  • There may be multiple procedures with multiple trigger conditions defined at each behavior component.
  • The DaVinci ECU-Callback object is superseded by the trigger concept and thus no longer available
  • Possible triggers are: State changes, Timer, Signals
  • The Simulink/TargetLink blocksets are enhanced by a procedure block

Task-Mapping

  • Task-Mapping for software components is now defined in the mapping view of the Hardware & Mapping Editor
  • See topic "Task mapping of software components" within the DaVinci online help for detailed information

Iterative OSEK Configuration

  • Changes in the OSEK configuration made in the OIL-Configurator are now read back and stored into the DaVinci workspace.
  • Storage is done for each ECU separately and can be modified through the OIL-Configurator without losing previous modifications
  • Additional OIL-Files can be attached at the ECU or software component

TargetLink 2.0

  • Implementation of behavior components can now be done with TargetLink 2.0 using MATLAB R13.
  • An upgrade mechanism of DaVinci models from TargetLink 1.3 to 2.0 is supported
  • A data dictionary is used for each behavior component with additional pool definitions for DaVinci
  • The single XML-Files for pool definitions can be found in <DaVinci>\Generation\Behavior\Matlab\R13\TL20\config
  • The previous implementation of TargetLink 1.3 using MATLAB R12 is still available.

Fixed issues

  • Attached files are now stored with paths relatively to the working folder
  • Linker problem with multiple RTW generated Stateflow files at the same ECU
  • Under rare circumstances modifications at attached files may be lost if working on the same behavior component with both DaVinci tools in parallel
  • Unhandled exception if output dir can't be created during code generation
  • Wrong ESM procedure execution during startup of CANoe simulation
  • Usage of ESM on ECUs without mapped software component leads in code generation errors

(top)


DaVinci Tool Suite Version 1.0 (SP3)

Parallel working with both DaVinci tools on the same workspace

  • Convenient switching between the tools without closing the workspace
  • Parallel editing of the objects without mutual blocking of the tools

Enhanced Target Package architecture and selection

  • Selection of used Target Package at each ECU and Mapping-System
  • Parallel installation of Target Packages in different versions supported

DaVinci Documentation Browser

  • New convenience tool to display documents and help files of DaVinci tools and Target Packages

MATLAB/Simulink Import

  • Recursive import of a Simulink subsystem as DaVinci software component structure

Internal Perl usage

  • External Perl installation no longer required
  • DaVinci installs Perl (build from CPAN sources Version 5.8.0) locally into the DaVinci generation directory
  • Any other Perl installations may exists on the PC and will not affect DaVinci code generation

DBC file export

  • Export of a mapping systems as dbc files

DBC Import

  • Support of sub-signals
  • Renaming of attached DBC-Files
  • Some minor roundup features and fixed issues
    • Enhanced check of DBC import conflicts
    • Check on imported DBC message ID while creating DaVinci messages
    • No more inconsistencies when deleting a DBC-imported signal from a bus interface
    • Correct update of properties on DBC-imported signals
    • Interpretation of some signal attributes corrected: start bit, init value, timeout

Configuration Management

  • Permanently disconnecting a workspace from a configuration management repository

Fixed issues

  • Generation rebuild fails without warning if output files are locked by another application
  • Attachment of large files via network was extremely slow
  • Compiler parameter settings are not stored after closing/reopen workspace
  • Opening a .dvw file through Windows Explorer doesn't work under some circumstances

(top)


DaVinci Tool Suite Version 1.0 (SP2)

Rework of target package settings

Please check and adapt your settings within the Mapping-Systems

  • Communication system type is now specified the Bus and no longer at each ECU
  • New generation parameter dialog at the Mapping-System and their ECUs available
  • CANoe firmware generation is now specifiable at each ECU within the Mapping-System

New DBkom version 2.48

  • Please adapt all workspaces using older DBKom versions at the ECU and Mapping-System

CAN Multi-Channel support

  • Support for more than one CAN-Channel at an ECU with DBKom communication system

Software System Sheets

  • Graphical grouping of components on several sheets
  • Cross reference links to follow signal paths across sheets

MATLAB/Simulink Export

  • Export of a Software System as one MATLAB/Simulink model containing all models attached to the used software components

MATLAB/Simulink/TargetLink functional interface

Please re-generate your existent, attached models with the enhanced blockset

  • Enhanced signal blockset with additional parameter
  • Additional blockset for ECU State Manager and Network Management

XML Import/Export

  • Software Component exchanged (incl. attached files) via XML

New CPU-Variants available

  • S12DG128
  • HC12DG128

Attached files enhancements

  • Additional attached files at the ECU within the Mapping-System
  • Support for binary file types (OBJ, LIB)
  • Additional file categories to specify file action within the generation make process

Fixed issues

  • Objects names within the Mapping-System are not checked correctly on uniqueness
  • Online help couldn't be started through adapter dialogs
  • Messages without bus signals are deleted during Mapping-System update
  • Missing explorer update after importing or selecting bus signals through a bus interface
  • Crash in subseqently renaming of component procedures
  • Missing connections when calling 'Complete Device Accessors' function
  • Wrong model name in initial TargetLink model generation

(top)


DaVinci Tool Suite Version 1.0 (SP1)

Fixed issues

  • After installation on a clean PC, an immediate Simulink generation will fail due to missing path settings
  • Some ECU specific parameters of the communication system can't be saved
  • Wrong Signal-Prefix (dvFwSim instead of dvFw) in template generation of Initial I/O Firmware for real ECUs
  • Missing update in Hardware-System explorer after creating new ECUs or Buses
  • Missing bus signals in Mapping-System after ECU exchange
  • Renaming of configurations may corrupt workspace and configuration management interaction
  • Component interface can't be removed in interface view under some circumstances
  • The same Signal in different versions can be used within one component. This is inconsistent and must not be allowed.
  • General error during code generation if the Mapping-System is read-only (i.e. checked in)
  • Renaming of generic attributes is not possible
  • Copy & Paste of diagnostic settings for an ECU is missing
  • ECUs without bus-signals won't be generated correctly
  • Missing check on unique sensor/actuator names
  • Wrong Network Management ID generation in DBC file

(top)


DaVinci Tool Suite Version 1.0

Extra installation of ActivePerl required

It is required to install ActivePerl Version 5.6.1 build 631 or higher in a separate step. ActivePerl may be downloaded from ActiveState at http://www.activestate.com/Products/ActivePerl/

Workspace conversion

A conversion of older workspaces with DTD 1.x to DTD 2.0 has to be performed for loading with DaVinci 1.0. There are two possibilities to perform this step:

  • Implicitly: Loading a workspace will automatically display a dialog for conversion.
    Please read the notes in this dialog carefully
  • Explicitly: Use the DVCvt.exe console application to convert a workspace with parameter -d2.0
    The parameter -f is always active for conversions to DTD 2.0, i.e. the workspace will always be saved in the new version

New Interaction Layer Versions

Please adapt all workspaces using older target settings at the ECU and Mapping-System:

  • DBKom 2.46
  • GM-LAN 3.99
  • Vector-IL 3.99

Configuration Management

  • Integration of Microsoft Visual SourceSafe

Diagnostic Support

  • Integration of CANdela and CANdesc for GM-LAN
  • Automatic creation of diagnostic stubs

ECU State Manager

  • Design of ECU State Machines
  • Definition of procedures with conditional execution

MATLAB/Simulink import

  • Import of a Simulink subsystem as DaVinci software component

Support of ECUs with predefined communication (DBC-Import)

  • Import of messages and signal mapping when using the auto-mapper for bus signals

Support for PowerPC Target

  • Target Package for MPC555 with DBKom 2.46 available

Signal states

  • Specification of signal error conditions at design time
  • Extensions of DaVinci Target API for accessing the signal state

(top)


DaVinci Tool Suite Version 0.9.8

Changes in the Target API

  • Please replace the following function calls in the behavior code of the C-coded components:
    • "dvSetSignalRequest()" by "dvRequestSignal(DV_SIGREG_ALL)"
    • "dvClearSignalRequest()" by "dvReleaseSignal(DV_SIGREG_ALL)"
    • "dvSignalsAvailable()" by individual calls of "dvGetState<SignalName>()"
  • Interface to CAN-Transceiver handling changed for systems using CCL (e.g. GM-LAN)
    see CodeGenerationManual.pdf and exemplary attached file HC12_Transceiver.c at the ECUs

SoftwareSystem Table Editor

  • Tabular viewing and editing of SoftwareSystems without graphic

Display of realization type in component graphic

  • Components will now have a visual distinction if they are included, structure or behavior components

Target Selection of attached files

  • Firmware and component files get a new attribute to specify, if they are used in PC- and/or Real-Target

Support for Logical Networks (LN)

  • Support for Logical Networks (LN)
    • LN Definition in Software-System
    • Integration with GM-LAN 3.97.00 Virtual Networks
    • Import of SAAB 3FD Models into DaVinci with LN

Performance Enhancements

  • Opening Component Mapping

Fixed issues

  • Unmapped signals won't be displayed within Mapping-System check
  • Wrong display of open signal paths
  • No Mapping-System check after assigning a signal to a sensor
  • No status information text output for a missing Software- or Hardware-System

(top)


DaVinci Tool Suite Version 0.9.7 (SP1)

Fixed issues

  • Linker error with multiple Simulink R13 models in one ECU
  • Check-State of mapping system not displayed correctly
  • Assertion, when activating a Mapping-System with attached DBC-File

(top)


DaVinci Tool Suite Version 0.9.7

GM-LAN Integration

  • Support of GM-LAN for Canoe and HC12 Target without Virtual Networks

Workspace DTD Converter Tool (DVCvt.exe)

  • Conversion of workspaces to a newer data model version

Sorting of Trees

  • All Explorer Trees (Global, Favorites, Categories) are now sorted

Name length limitation of 32 characters

  • All object names are now limited to a length of 32 characters to ensure proper usage in code generation and DBC-Files

Workspace Path checking

  • Workspace naming and path length will now be checked to ensure a maximum path length of 260 characters

Performance Enhancements

  • Loading Signals and Components
  • Editing Signal Types

Fixed issues

  • Disconnecting an ECU from a Bus causes an error
  • In some situations, renaming of objects was impossible
  • "New Workspace" command doesn't work in Hardware&Mapping Editor
  • Creating a new object category with an existing name will crash

(top)


DaVinci Tool Suite Version 0.9.6 (SP1)

Support for MATLAB R13

  • Adaptation of code generation for MATLAB R13 using RTW-GRT

(top)


DaVinci Tool Suite Version 0.9.6

Support of Large Systems

  • Rework of object loading and tree display
  • Enhancements in graphic display
  • Smart update mechanisms in tools (Trees, Object-Viewer and Graphic)
  • Rework of Mapping-System data update mechanisms

Object Categories

  • User defined grouping of objects with categories
  • Favorite Lists

Enhanced checking of attached files

  • Hints on closing, saving and generating if attached files are not up-to-date

XML Import Tool (DVImEx.exe)

  • Import of SAAB 3FD Models into DaVinci

Usability

  • Stop-Button for Code Generation added
  • Generate-All command added
  • Save-Button won't be grayed if workspace is not modified

Perl Installation Check

  • New script DVPerlCheck.pl to retrieve information about current Perl installation

Fixed issues

  • Missing update on DBC-Signal import
  • Mapping system consistency: Sensor signal specified as actuator is not detected as error
  • Overlapping display of interface names
  • Property windows of a message causes a crash
  • Multiple Tx-nodes of Tx-messages crashes in DB-Kom
  • Deleting a SWS corrupts the Mapping-System

(top)


Additional Information

Copyright

Vector Informatik GmbH

Certified Quality Management System

The Quality/Process Management of Vector Informatik GmbH is being certified according to DIN EN ISO 9001:2000-12 (formerly DIN EN ISO 9001:1994-08) throughout since 1998-08-19.

Vector Informatik GmbH - Addresses

Vector Informatik GmbH
Ingersheimer Str. 24
D-70499 Stuttgart, Germany
Tel.: +49 (711) 80670-0
Fax: +49 (711) 80670-100
info@vector-informatik.de
http://www.vector-informatik.com

Subsidiaries

Vector France SAS
168, Boulevard Camlinat
92240 Malakoff
France
Tel.: +33 1 4231 4000
Fax: +33 1 4231 4009
information@vector-france.com
http://www.vector-france.com

Vector Japan Co., Ltd.
Seafort Square Center Bld.
18F, 2-3-12,
Higashi-shinagawa, Shinagawa-ku
Tokyo 140-0002
Japan
Tel.: +81 3 5769 6970
Fax: +81 3 5769 6975
info@vector-japan.co.jp
http://www.vector-japan.co.jp

VecScan AB
Theres Svenssons Gata 9
417 55 Gothenburg
Sweden
Tel.: +46 (31) 76476 00
Fax: +46 (31) 76476 19
info@vecscan.com
http://www.vecscan.com

Vector CANtech, Inc.
39500 Orchard Hill Place
Suite 550
Novi, Michigan 48375
USA
Tel.: +1 (248) 449-9290
Fax: +1 (248) 449-9704
info@vector-cantech.com
http://www.vector-cantech.com

Vector Korea IT Inc.
Daerung Post Tower III, 508
182-4 Guro-dong, Guro-gu
Seoul 152-790
Republic of Korea
Tel.: +82(0)2 2028 0600
Fax: +82(0)2 2028 0604
info@vector-korea.com
http://www.vector-korea.com

Vector GB Ltd.
Rhodium
Central Boulevard
Blythe Valley Park
Solihull, Birmingham
West Midlands B90 8AS
United Kingdom
Tel.: +44 (0) 7530 264701
info@vector-gb.co.uk
http://www.vector-gb.co.uk

(top)


36 -

W3C Software License

W3C SOFTWARE NOTICE AND LICENSE

http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231

This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.

Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications:

  1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
  2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software Short Notice should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code.
  3. Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.)

THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders.

____________________________________

This formulation of W3C's notice and license became active on December 31 2002. This version removes the copyright ownership notice such that this license can be used with materials other than those owned by the W3C, reflects that ERCIM is now a host of the W3C, includes references to this specific dated version of the license, and removes the ambiguous grant of "use". Otherwise, this version is the same as the previous version and is written so as to preserve the Free Software Foundation's assessment of GPL compatibility and OSI's certification under the Open Source Definition. Please see our Copyright FAQ for common questions about using materials from our site, including specific terms and conditions for packages like libwww, Amaya, and Jigsaw. Other questions about this notice can be directed to site-policy@w3.org.
 

Joseph Reagle <site-policy@w3.org>

Last revised $Id: copyright-software-20021231.html,v 1.11 2004/07/06 16:02:49 slesch Exp $