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/A
MDD
N/A
Source Code
N/A
PolySpace
N/A
Integration Manual
N/A
Davinci 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.
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.
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.
Author(s) Christian Weber, Hannes Futter, Marco Wierer Restrictions Customer confidential - Vector decides Abstract Configuration of Multiple ECUs with Vector's AUTOSAR BSW stack.
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>
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
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.
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: VectorGB 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
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
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.
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).
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
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 a 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 4Ensure 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 2For 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 4Save 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 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 2Enter 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 2For 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 2For 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 4Send 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 2Enter 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 3Ensure 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 2For 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 5Send 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 7If 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 2Enter 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
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 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 Counterof 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 Connectedmenu 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
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 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:
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 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) Platform 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)
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: * ================ *
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:
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)
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 C 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
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 1Overview ......................................................................................................................... 5 1.1 Intended Audience .......................................................................................... 5 1.2 Terms and Acronyms ....................................................................................... 5 2The ECU-Configuration Process ................................................................................... 7 2.1 The ECU-Configuration File ............................................................................ 8 3DaVinci 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 4ECU-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 5Best 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 6Contact ......................................................................................................................... 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
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.
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
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
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, a 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
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/ w Implicit OsAlarmAccessingApplication w Implicit OsAlarmAction/
Implicit OsAlarmActivateTask/
Implicit OsAlarmActivateTaskRef w Implicit OsAlarmSetEvent/
Implicit OsAlarmSetEventRef w Implicit OsAlarmSetEventTaskRef w Implicit OsAlarmCounterRef w Explicit OsEvent/ w Implicit OsEventMask w Implicit OsApplication/ w Explicit / Implicit OsTrusted r/w Explicit / Implicit OsAppAlarmRef w Implicit OsAppResourceRef w Implicit OsAppTaskRef w Implicit OsApplicationTrustedFunction/
Implicit OsTrustedFunctionName w Implicit OsApplicationParams (MICROSAR) w Implicit OsApplicationReturnType (MICROSAR) w Implicit OsApplicationGenerateStub (MICROSAR) w Implicit OsCounter w Explicit OsResource/ w Implicit OsResourceProperty w 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 w Implicit OsTaskAutostart/
Implicit OsTaskAppModeRef r/w Implicit OsTaskAppMode w Implicit OsTaskEventRef w Implicit OsTaskResourceRef w Implicit OsTaskAccessingApplication w 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
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 w Implicit/Explicit NvmRamBlockDataAddress w Implicit NvmRomBlockDataAddress w Implicit NvmNvramBlockIdentifier r/w Explicit NvmBlockUseSyncMechanism w Implicit NvmWriteRamBlockToNvCallback w Implicit NvmReadRamBlockFromNvCallback w 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
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) r (Explicit) BoardEnableSnvPrefixes (MICROSAR) r (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
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.
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.
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
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
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
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
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’).
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:
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:
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:
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
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 1History....................................................................................................................... 2 2About this Document ............................................................................................... 3 3Use Cases ................................................................................................................. 4 4Approach .................................................................................................................. 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 5Special Import Functions......................................................................................... 9 5.1 Overwrite Import Mode Preset .................................................................. 10 5.2 Update Diagnostic Configuration .............................................................. 11 6Contact.................................................................................................................... 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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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"
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
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
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'
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
"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.
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.
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.
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
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
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
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
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
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
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
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
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.
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.
Additional export of user-defined attributes in a separate AUTOSAR XML file see 'TechnicalReference_UserDefinedAttributeExport.pdf' in DaVinci Documentation Browser
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
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
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
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
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
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
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 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
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:
The full text of this NOTICE in a location viewable to users of the
redistributed or derivative work.
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.
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.