This is the multi-page printable view of this section. Click here to print.
Tools (scripting, external tools...)
- 1: Artt (TL105A)
- 1.1: ReleaseNotes_Artt_Generator
- 1.2: ReleaseNotes_Artt_Generator_ind
- 1.3: ReleaseNotes_Artt_Generators
- 2: DataDict (TL117A)
- 3: Davinci (TL102A)
- 3.1: TL102A_Davinci Peer Review Checklists
- 3.2: about
- 3.3: about
- 3.4: about
- 3.5: about
- 3.6: ApplicationNotes_DifferenceAnalyzer
- 3.7: ApplicationNotes_DifferenceAnalyzer_ind
- 3.8: ApplicationNotes_DifferenceAnalyzers
- 3.9: LicenseManagerHelp
- 3.10: LicenseManagerHelp_ind
- 3.11: LicenseManagerHelps
- 3.12: TechnicalReference_AutoConnect
- 3.13: TechnicalReference_AutoConnect_ind
- 3.14: TechnicalReference_AutoConnects
- 3.15: TechnicalReference_DataTypes_AR4
- 3.16: TechnicalReference_DataTypes_AR4_ind
- 3.17: TechnicalReference_DataTypes_AR4s
- 3.18: TechnicalReference_EcuConfigurationFiles
- 3.19: TechnicalReference_EcuConfigurationFiles_ind
- 3.20: TechnicalReference_EcuConfigurationFiless
- 3.21: TechnicalReference_UserDefinedAttributeExport
- 3.22: TechnicalReference_UserDefinedAttributeExport_ind
- 3.23: TechnicalReference_UserDefinedAttributeExports
- 3.24: UserManual_DataImport
- 3.25: UserManual_DataImport_ind
- 3.26: UserManual_DataImports
- 3.27: UserManual_Working_with_DCF
- 3.28: UserManual_Working_with_DCF_ind
- 3.29: UserManual_Working_with_DCFs
- 3.30: Welcome
- 3.31:
- 3.32:
- 3.33:
- 4: MfgSrvSuprt (TL113A)
- 5: PAGe (TL125A)
- 5.1: PAGe_ReleaseNotes
- 5.2: PAGe_ReleaseNotes_ind
- 5.3: PAGe_ReleaseNotess
- 5.4: PAGe_Review
- 5.5: PAGe_UserManual
- 5.6: PAGe_UserManual_ind
- 5.7: PAGe_UserManuals
- 6: Python (TL112A)
- 6.1: pylint.1
- 6.2: TL112A_Python Peer Review Checklist
- 6.3: sgml_input
- 6.4: test_difflib_expect
- 7: Python3 (TL119A)
- 7.1: Python3_Review
- 7.2: help
- 7.3: sgml_input
- 7.4: test_difflib_expect
- 8: SwcSuprt (TL109A)
1.1 - ReleaseNotes_Artt_Generator
1.2 - ReleaseNotes_Artt_Generator_ind
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
1.3 - ReleaseNotes_Artt_Generators

BMW Package Release Notes
Artt_Generator-2.0.2
Version:
2.0.2
Release Date:
23-Nov-2011
Package Status:
Released
Author:
BMW Group
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 1 of 14
1 Revision History
Revision
Date
Remarks
2.0.2
23-Nov-2011
CR71146, CR71147.
2.0.1
14-Apr-2011
Method ModuleConfAtDefRefTo() added CR71008.
2.0.0
15-Mar-2011
Behaviour of ValueOf() changed CR71004,
CR71005.
1.3.0
11-Oct-2010
AUTOSAR 4.0 schema CR .
1.2.0
30-Jun-2010
New validation feature CR70359, CR .
1.1.1
27-May-2010
CR70519.
1.1.0
11-Nov-2009
User friendliness and portability CR70397,
CR70343.
1.0.3
27-Oct-2009
Performance optimization CR70341.
1.0.2
29-Jun-2009
Support of more BAC2.1 templates. CR70168,
CR70166, CR70167, CR70195, CR70237,
CR70267.
1.0.1
03-Oct-2008
Initial revision. CR70051, CR70068.
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 2 of 14
2 Package Enumeration Scheme
Every package carries a 3-digit version number. The following table explains how compatibility
between versions can be determined from the version number:
Changed Version
Example
Compatibility
Patch Version
ĺ
A defect has been fixed. Versions are fully
compatible.
Minor Version
ĺ
A new feature was added. New version is
backwards compatible to old version.
Major Version
ĺ
API of package changed. Versions are not
compatible. If the new package is used, other
packages must be changed as well.
3 Package Description
artt is a command line application allowing to generate text files, including source code, from
AUTOSAR descriptions. As input data artt uses a template file describing static content and
structure of the desired output and one or more AUTOSAR descriptions, which are serving as
provider for dynamic content. Since AUTOSAR descriptions are XML files, templates for artt
typically use XPATH expressions referring to certain elements in the input file.
This package is maintained by BMW AUTOSAR Core Support, via Request Tracker (https://sc-
support.bader-muenchen.de/rt3/) or telephone hotline (+49-89-382-32233).
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 3 of 14
4 Revisions and Modifications
Revision 2.0.2 [Released]
Item
Description
CR ID:
71146
CR Headline:
ARTT ChangeContext returns false when called with null as
parameter.
Description of Issues:
Misleading documentation
Description of Changes:
Extended the documentation of ChangeContext method in
ArGtcBase to reflect that a call to ChangeContext(null) will
successfully reset the context to the root context AND return false.
(although one could expect that it returns true because the context
change was successfull.
Changed Files:
artt.chm
Compatibility:
Fully compatible
Item
Description
CR ID:
71147
CR Headline:
Wrong implementation of BoolValueOf
Description of Issues:
The included template utility file Helper.tt contained a helper
function BoolValueOf. This implementation was wrong since it did
not respect the various representations of bool-values allowed by
the autosar schema.
Description of Changes:
Changed the implementation to use the correct artt internal
implicit bool operator to map a ValueNode to a bool.
Marked the helper function BoolValueOf and its wrapper Enabled
() as being obsolete since these helpers can simply be substuitted
with core artt functions.
Changed Files:
Helper.tt
Compatibility:
Fully compatible
Item
Description
CR ID:
CR Headline:
Description of Issues:
Description of Changes:
Changed Files:
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 4 of 14
Revision 2.0.1 [Stable]
Item
Description
CR ID:
71008
CR Headline:
new method ModuleConfAtDefRefTo()
Description of Issues:
New method ModuleConfAtDefRefTo() added.
Description of Changes:
Creates XPATH to the <c>MODULE-CONFIGURATION</c> node
(for AUTOSAR versions before 4.0)
or the <c>ECUC-MODULE-CONFIGURATION-VALUES</c>
node (starting with AUTOSAR version 4.0) of the module
configuration that is based on the module definition with the given
shortname.
Changed Files:
artt.exe
artt.chm
Compatibility:
no restrictions to older AUTOSAR versions
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 5 of 14
Revision 2.0.0 [Stable]
Item
Description
CR ID:
71004
CR Headline:
artt generator shall write output file even in case of error
Description of Issues:
Also for Environment.Exit in template file an outputfile is
generated.
Description of Changes:
Also in case of a thrown exception in template file an output file is
generated.
Changed Files:
artt.exe
Compatibility:
no restrictions to older AUTOSAR versions
Item
Description
CR ID:
71005
CR Headline:
ValueOf-Method shall not try to interprete ECUC-BOOLEAN-
VALUE
Description of Issues:
In versions less the 2 the ValueOf() method returned the string
found in the tt-file if it was not a boolean value. In case of a
boolean value, it retruned "TRUE" or "FALSE".
Description of Changes:
The method ValueOf() now always returns just the string found in
the template file without an interpretation of it.
Changed Files:
artt.exe
Compatibility:
Instead of writing:
boolean blub = <#= ValueOf(<xpath to BOOLEAN-VALUE>) #>
now it has to be written:
boolean blub = <#= (ValueOf(<xpath to BOOLEAN-VALUE>) ==
true ? “TRUE” : “FALSE”) #>
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 6 of 14
Revision 1.3.0 [Released]
Item
Description
CR ID:
CR Headline:
Handling of the changed tags in AUTOSAR 4.0 schema.
Description of Issues:
- ECUC-MODULE-CONFIGURATION-VALUES instead of
MODULE-CONFIGURATION (in AR < V3.x)
- ECUC- PARAM-CONF-CONTAINER-DEF instead of PARAM-
CONF-CONTAINER-DEF (in AR < V3.x)
Description of Changes:
Changed tags of AUTOSAR V4.0 are supported now. Depending
on the URL given in the template or via the commandline, the tag
name of AUTOSAR 2.x, 3.x or 4.x is used.
Changed Files:
artt.exe
artt.chm
Compatibility:
no restrictions to older AUTOSAR versions
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 7 of 14
Revision 1.2.0 [Stable]
Item
Description
CR ID:
70359
CR Headline:
Validation of AUTOSAR descriptions
Description of Issues:
The ARTT generator has no ability to validate the given EPC file
against the BMD. This has the following disadvantages:
- Existence of nodes can not be ensured
- MIN/MAX/RANGE tags can not be evaluated
- Type checks of variables can not be done
- Uniqueness of container entries can not be verified
Description of Changes:
Implemented validation of AUTOSAR description (EPC) against
AUTOSAR definition (BMD). Validation can be triggered by
specifiying the AUTOSAR definition file on the command line. See
user guide for more information.
Changed Files:
artt.exe
artt.chm
Compatibility:
Item
Description
CR ID:
CR Headline:
Push- / PopContext functionality
Description of Issues:
Functionality was needed for Validation of AUTOSAR
descriptions.
Description of Changes:
New set of functions added to manipulate the context using a
stack: PushContext(), PopContext(), ClearContextStack().
See user guide for more information.
Changed Files:
artt.exe
artt.chm
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 8 of 14
Revision 1.1.1 [Released]
Item
Description
CR ID:
70519
CR Headline:
Artt-Generator continous generating even if verify failed
Description of Issues:
Artt-Generator returns success of generation.
Description of Changes:
Artt-Generator does not return value if successfull generated.<> 0.
Changed Files:
logger.tt
Compatibility:
Revision 1.1.0 [Stable]
Item
Description
CR ID:
70397
CR Headline:
Improve user friendliness
Description of Issues:
In some cases of wrong command line parameters the return
value was an errorlevel of 0.
Description of Changes:
Help file extened with the information, that a not existing output
folder is created.
In case of a wrong command line parameter, the program returns
an errorlevel <> 0.
Changed Files:
artt.chm
artt.exe
Compatibility:
Item
Description
CR ID:
70343
CR Headline:
Include search path
Description of Issues:
The usage of the templates with includes in build systems with
different folder structures was not possilbe.
Description of Changes:
It is now possible to declare an search path for the includes given
in an template via command line parameter -i.
Changed Files:
artt.exe
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 9 of 14
Revision 1.0.3 [Stable]
Item
Description
CR ID:
70341
CR Headline:
ARTT Performance Issue
Description of Issues:
For large .epc files the template generation takes a long time
because of the xpath search.
Description of Changes:
Performance optimizations done with different means.
- Caches for Autosar shortnames to xpaths.
- Working with compiled xpaths.
Changed Files:
artt.exe
Compatibility:
Revision 1.0.2 [Stable]
Item
Description
CR ID:
70168
CR Headline:
ARTT: Missing Include Directives.
Description of Issues:
Although ARTT documentation references MS T4 documentation
(which ARTT is based on), ARTT currently does not support
Template Include directives.
Description of Changes:
Added support for T4 <#@include #> directive.
Changed Files:
artt.exe
artt.chm
SswcT4EngineHost.dll
Compatibility:
Item
Description
CR ID:
70166
CR Headline:
ARTT: String variables as XPATH-Expression in LOOP.
Description of Issues:
Currently only String Literals in the form "xxx" are accepted as a X
-PATH expression in a LOOP-statement.
Description of Changes:
Fixed issue with expressions other than non-verbatim string
literals being used in LOOP macros. Now all expressions are
possible.
Changed Files:
artt.exe
artt.chm
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 10 of 14
Item
Description
CR ID:
70167
CR Headline:
ARTT: Warnings shall not abort the generation process.
Description of Issues:
The ARTT generator aborts the generation process if warnings
(like "unused variables") are encountered.
Description of Changes:
Warnings no longer result in a generation error, i.e. the calling
code will no longer abort the build in case of template warnings.
Changed Files:
artt.exe
artt.chm
Compatibility:
Item
Description
CR ID:
CR Headline:
Number of processed AUTOSAR files no longer limited.
Description of Issues:
Number of AUTOSAR descriptions was limited.
Description of Changes:
The number of AUTOSAR description files is no longer limited. As
consequence the configuration file artt.config, which specified the
used upper limit is no longer required.
Changed Files:
AutosarDirectiveProcessor.dll
artt.exe
artt.chm
SswcT4EngineHost.dll
artt.config (removed)
artt.exe
*.dll removed
artt.exe
artt.chm
artt.exe
artt.chm
Compatibility:
An old artt.config will not be used and therefore has no influence
on the application.
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 11 of 14
Item
Description
CR ID:
70195
CR Headline:
ARTT-Generator: New convenience functions for template
creation.
Description of Issues:
The functions of interest are:
- RefValueExists() (a combination of the existing functions Exists()
and RefValueOf())
- AppendTrailingSpaces()
- LastStringAfterSlash(string xpath)
- bool BitTest(int val, bitNo)
- xpath creators (ShortName(), DefRef(), ...)
- ToHex(...)
- BoolFromString()
Description of Changes:
A number of new functions have been added. In order to fit
existing architecture, original function names were used as
suggestion and were adapted as specified below.
The following utility functions have been added to artt: BitTest(),
Xp.DefRefTo(), Xp.ValueAtDefRefTo(), Xp.ValueRefAtDefRefTo(),
LastValueSegmentOf(), ModuleConf(), Xp.ShortNamePath(),
Assert(), FormatHex(), AsBool(), RefExists().
See user guide for detailed information about the functionality of
new and existing methods.
Changed Files:
artt.exe
AutosarDirectiveProcessor.dll
artt.chm
Compatibility:
Item
Description
CR ID:
70237
CR Headline:
Extension of XPathFactory functionality
Description of Issues:
Better usablility.
Description of Changes:
New XPathFactory.ContainerAtDefRefTo(): Creates XPath for a
certain container node.
Change function XPathFactory.ModuleConf(): Return absolute
XPath instead of relative.
New function FormatBin(): format integer to binary format with
variable length.
new commandlineswitches for overwrite the name of the
generated file and the namespace URI in the template
Changed Files:
artt.exe
artt.chm
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 12 of 14
Item
Description
CR ID:
70267
CR Headline:
Validation of the given XML against a schema
Description of Issues:
Description of Changes:
Function to validate the .epc files against a via commandline
given .xsd schema.
Changed Files:
artt.exe
artt.chm
Compatibility:
Revision 1.0.1 [Stable]
Item
Description
CR ID:
CR Headline:
Support of relative XPATH references.
Description of Issues:
Description of Changes:
A new feature supporting relative XPATH references has been
added through the ChangeContext() command.
Changed Files:
artt.exe
artt.chm
AutosarDirectiveProcessor.dll
Compatibility:
Item
Description
CR ID:
70051
CR Headline:
Artt-Generator: Failure when called from network drive.
Description of Issues:
When called from a network drive, artt cannot be executed due to
a .NET runtime exception.
Description of Changes:
artt executable and all required libraries were signed with a BMW
signature. The signature can be imported on Windows machines
that need to call artt from a network path.
Changed Files:
artt.exe
artt.chm
AutosarDirectiveProcessor.dll
SswcT4EngineHost.dll
Microsoft.VisualStudio.TextTemplating.dll
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 13 of 14
Item
Description
CR ID:
70068
CR Headline:
LOOP processing of XML nodes.
Description of Issues:
Description of Changes:
A new feature was added to support looping over a set of
referenced XML nodes through the LOOP command.
Changed Files:
artt.exe
artt.chm
AutosarDirectiveProcessor.dll
Compatibility:
Copyright (c) 2010 by BMW Group. All rights reserved.
Page 14 of 14
Document Outline
2.1 - DataDict Peer Review Checklists
Overview
Summary SheetSynergy Project
3rd Party Files
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
Sheet 3: 3rd Party Files
2.2 - Overrides_Template
Overview
Program DefinitionOverrides
Sheet 1: Program Definition
Sheet 2: Overrides
| Calibration Base Name | Component | Cal Region | Configuration | Online Group | Impact | Customer Visible | Tuning Owner | Safety Rating | Size | Required Memory | 
| 0 | ||||||||||
| 0 | ||||||||||
| 0 | 
3 - Davinci (TL102A)
Davinci (TL102A)
Component Documentation
Specific Component Tools
- about.html
- about.html
- about.html
- about.html
- ApplicationNotes_DifferenceAnalyzer.html
- ApplicationNotes_DifferenceAnalyzer.pdf
- ApplicationNotes_DifferenceAnalyzer_ind.html
- ApplicationNotes_DifferenceAnalyzers.html
- LicenseManagerHelp.html
- LicenseManagerHelp.pdf
- LicenseManagerHelp_ind.html
- LicenseManagerHelps.html
- TechnicalReference_AutoConnect.html
- TechnicalReference_AutoConnect.pdf
- TechnicalReference_AutoConnect_ind.html
- TechnicalReference_AutoConnects.html
- TechnicalReference_DataTypes_AR4.html
- TechnicalReference_DataTypes_AR4.pdf
- TechnicalReference_DataTypes_AR4_ind.html
- TechnicalReference_DataTypes_AR4s.html
- TechnicalReference_EcuConfigurationFiles.html
- TechnicalReference_EcuConfigurationFiles.pdf
- TechnicalReference_EcuConfigurationFiles_ind.html
- TechnicalReference_EcuConfigurationFiless.html
- TechnicalReference_UserDefinedAttributeExport.html
- TechnicalReference_UserDefinedAttributeExport.pdf
- TechnicalReference_UserDefinedAttributeExport_ind.html
- TechnicalReference_UserDefinedAttributeExports.html
- UserManual_DataImport.html
- UserManual_DataImport.pdf
- UserManual_DataImport_ind.html
- UserManual_DataImports.html
- UserManual_Working_with_DCF.html
- UserManual_Working_with_DCF.pdf
- UserManual_Working_with_DCF_ind.html
- UserManual_Working_with_DCFs.html
- Welcome.html
3.1 - TL102A_Davinci Peer Review Checklists
Overview
Summary SheetSynergy Project
3rd Party Files
Sheet 1: Summary Sheet
Sheet 2: Synergy Project
Sheet 3: 3rd Party Files
3.2 - about
About This Content
June 28, 2007
License
The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor's license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
Third Party Content
The Content includes items that have been sourced from third parties as set out below. If you did not receive this Content directly from the Eclipse Foundation, the following is provided for informational purposes only, and you should look to the Redistributor’s license for terms and conditions of use.
Flute 1.3
The plug-in is accompanied by software developed by W3C at http://www.w3.org/Style/CSS/SAC/. Flute 1.3 ("Flute") is included with the plug-in without modification in lib/flute.jar. Your use of Flute is subject to the terms and conditions of the W3C Software License ("W3CSL"). A copy of the W3CSL can be found in about_files/copyright-software-20021231.htm and is also available at http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231. Source code for Flute is available at http://www.w3.org/Style/CSS/SAC/.
3.3 - about
About This Content
June 5, 2006
License
The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributor’s license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
3.4 - 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.
3.5 - 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.
3.6 - ApplicationNotes_DifferenceAnalyzer
3.7 - ApplicationNotes_DifferenceAnalyzer_ind
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
3.8 - ApplicationNotes_DifferenceAnalyzers

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

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

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

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

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

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


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



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


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


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


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



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


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

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


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

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

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

DaVinci Difference Analyzer Application Note
7 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector-informatik.com
2015, Vector Informatik GmbH
Version: 1.7
3.9 - LicenseManagerHelp
3.10 - LicenseManagerHelp_ind
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
3.11 - LicenseManagerHelps

Vector Product Activation
Version 2.0
Status
Released


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


Vector Product Activation
1 Overview
In the product activation process only data relevant to the installation is transferred.
Vector uses the acquired data exclusively for product activation.
To activate the product open the Product License Manager. The required Activation ID
can be found on the cover of the Product CD or in your delivery e-mail.
You can choose between two different methods of product activation:
1. Online: Automatically via the Internet (recommended, since no time delay)
2. By e-mail to: activation@vector-worldwide.com
If you choose activation by e-mail, send the activation request generated in the Product
License Manager as an e-mail attachment to Vector. In response Vector will send you a
License Certificate by e-mail which you will need to enter in the License Manager. If this
is a first-time activation, the initial step involves an additional e-mail exchange to obtain
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 4 Ensure that you typed the Activation ID correctly. Press OK. Once the license has
been correctly transferred to your PC, you’ll see a respective message. You’re done.
Info
In case a HTTP proxy is present in your network that requires a password and/or a
login you will be prompted for that data.
2.1.2
Activate / Update a License via E-mail
To activate or update a license via Email (only recommended if activation via Internet
doesn't work), open the License Manager and follow these instructions:
Step 1 Select License Keys / Activate Manually / Vector Activation Server in the main
menu of the Product License Manager.
Step 2 For Request method, select Send request by e-mail
2011, Vector Informatik GmbH
Version: 2.0
5 / 22
based on template version 4.5



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



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




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




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




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




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




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




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




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




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



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




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



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




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




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







Vector Product Activation
6 FAQs and Background Information
FAQ
What options do I have if activation via Internet fails?
Check your proxy settings and retry activation via Internet. If it continues to fail, use
activation via e-mail.
FAQ
What options do I have if activation via e-mail fails?
Maybe you want to try direct activation via Internet – it is more convenient (see above).
Otherwise please contact Vector (activation@vector-worldwide.com) with a detailed
description of your actions and what happened.
FAQ
Should I trust Vector software to directly connect to the Internet?
Yes. In the product activation process, only data relevant to the installation are
transferred. Vector uses the acquired data exclusively for product activation. Vector
uses a wide-spread third-party product for implementing product activation, Acresso
FLEXnet (former Macrovision FLEXlm).
FAQ
My hard-disk crashed. How do I get a license for my new PC?
Please contact Vector (activation@vector-worldwide.com).
FAQ
I get a new PC. How do I move my license from the old to the new PC?
In Please contact Vector (activation@vector-worldwide.com).
2011, Vector Informatik GmbH
Version: 2.0
21 / 22
based on template version 4.5


Vector Product Activation
7 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com
2011, Vector Informatik GmbH
Version: 2.0
22 / 22
based on template version 4.5
Document Outline
- 1 Overview
- 2 Activate / Update a License
- 3 Extend a License
- 4 Return a License
- 5 Repair Licenses
- 6 FAQs and Background Information
- 7 Contact
3.12 - TechnicalReference_AutoConnect
3.13 - TechnicalReference_AutoConnect_ind
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
3.14 - TechnicalReference_AutoConnects
Auto-Connect Port Prototypes
Technical Reference
Version 1.0
Authors
Pavol Gramblicka
Status
Released
Technical Reference Auto-Connect Port Prototypes
Document Information
History
Author
Date
Version
Remarks
Pavol Gramblicka
2015-04-28
0.1.0
Initial version
Pavol Gramblicka
2015-04-28
1.0.0
Final version
2015, Vector Informatik GmbH
Version: 1.0
2 / 13
based on template version 5.2.0
Technical Reference Auto-Connect Port Prototypes
Contents
1
Overview ....................................................................................................................... 5
1.1
Intended Audience ............................................................................................. 5
1.2
Terms and Acronyms ......................................................................................... 5
2
Input Port Prototypes ................................................................................................... 6
3
Auto-Connect ................................................................................................................ 7
3.1
Auto-Connect – simple pattern ........................................................................... 7
3.2
Auto-Connect – enhanced patterns .................................................................... 9
3.2.1
Prefix, Postfix ..................................................................................... 9
3.2.2
Complex patterns using the component prototype name .................. 10
4
Contact ........................................................................................................................ 13
2015, Vector Informatik GmbH
Version: 1.0
3 / 13
based on template version 5.2.0
Technical Reference Auto-Connect Port Prototypes
Illustrations
Figure 2-1
Start the contextless auto-connecting ......................................................... 6
Figure 2-2
Start the context dependent auto-connecting .............................................. 6
Figure 3-1
Simple auto-connect scenario ..................................................................... 7
Figure 3-2
List of proposed connections ...................................................................... 8
Figure 3-3
Context dependent auto-connecting of a prefixed port prototype ................ 9
Figure 3-4
Context dependent auto-connecting with a prefixed naming pattern ........ 10
Figure 3-5
Context dependent auto-connecting of a port prototype without the
component restriction ............................................................................... 11
Figure 3-6
Context dependent auto-connecting of port prototypes with the
component restriction ............................................................................... 12
Tables
Table 1-1
Terms and Acronyms .................................................................................. 5
2015, Vector Informatik GmbH
Version: 1.0
4 / 13
based on template version 5.2.0
Technical Reference Auto-Connect Port Prototypes
1 Overview
DaVinci Developer is part of Vector’s solution for AUTOSAR compatible software design. It
is used to design and configure software components and provides various concepts to
support this process.
This document describes a part of the design process related to DaVinci Developer from a
technical point of view, trying to give the user a better understanding of the internal
processes and how the tool reacts in different situations.
1.1
Intended Audience
This document aims at developers who are involved in the AUTOSAR design process and
use DaVinci Developer to integrate various software components.
1.2
Terms and Acronyms
Term
Definition
DEV
DaVinci Developer
Table 1-1 Terms and Acronyms
2015, Vector Informatik GmbH
Version: 1.0
5 / 13
based on template version 5.2.0


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

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

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

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

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

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

Technical Reference Auto-Connect Port Prototypes
Figure 3-6 Context dependent auto-connecting of port prototypes with the component restriction
2015, Vector Informatik GmbH
Version: 1.0
12 / 13
based on template version 5.2.0
Technical Reference Auto-Connect Port Prototypes
4 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com
iA connectable port prototype is such a port prototype which allow for creation of a meaningful connector
prototypes. In case of an assembly connector, if P-Port is selected only an R-Port or PR-Ports are
meaningful and vice versa. In case of a delegation connector prototypes, if P-Port is selected only a P-Port
or PR-Port are meaningful and similar if an R-Port is selected only an R-Port or PR-Port are meaningful.
2015, Vector Informatik GmbH
Version: 1.0
13 / 13
based on template version 5.2.0
Document Outline
3.15 - TechnicalReference_DataTypes_AR4
3.16 - TechnicalReference_DataTypes_AR4_ind
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
3.17 - TechnicalReference_DataTypes_AR4s
Autosar 4.0 - DataTypes
Technical Reference
Version 1.1
Authors
Thomas Bruni
Status
Released
2014, Vector Informatik GmbH
Version: 1.1
1 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
Document Information
History
Author
Date
Version
Remarks
Thomas Bruni
11.11.2013
0.1
Document creation
Thomas Bruni
14.01.2014
0.2
Changes:
3.4 Platform types
Thomas Bruni
27.01.2014
0.3
Corrections in 3.4 Platform
types
Thomas Bruni
29.01.2014
0.4
Creation of 2 new chapters:
3.4 Data type mapping
5.4 Data type mapping
assistant
5.5 Type emitter
Thomas Bruni
21.02.2014
1.0
Release version
Thomas Bruni
14.03.2014
1.1
Changes
for
Mode
Declaration Group mapping:
chapters 3.4 and 4.4.
Reference Documents
No.
Source
Title
Version
[1]
AUTOSAR AUTOSAR_TPS_SoftwareComponentTemplate
4.2.0
[2]
AUTOSAR AUTOSAR_SWS_PlatformTypes
2.5.0
2014, Vector Informatik GmbH
Version: 1.1
2 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
Contents
1 Introduction .................................................................................................................... 6
2 Data Types and Data Prototypes ................................................................................... 7
3 Design of data prototypes in DaVinci tool chain .......................................................... 8
3.1 Data prototypes ........................................................................................................ 8
3.2 Application data types ............................................................................................ 10
3.3 Implementation data types ..................................................................................... 11
3.4 Data type mapping ................................................................................................. 14
3.5 Platform types ........................................................................................................ 15
3.5.1
Definitions ..................................................................................................... 15
3.5.1.1
Autosar Standard Types ......................................................................... 15
3.5.1.2
Platform Types ....................................................................................... 15
3.5.1.3
Valid C expression .................................................................................. 15
3.5.2
Practice ......................................................................................................... 16
3.5.2.1
Abstraction of SW from platform ............................................................. 16
3.5.2.2
Dependency between SW and platform ................................................. 17
3.5.2.3
Platform types and Vector DaVinci Tool suite .......................................... 18
3.6 Generation ............................................................................................................. 22
4 Design examples .......................................................................................................... 23
4.1 Primitive data element ............................................................................................ 23
4.2 Complex data element ........................................................................................... 36
4.3 Enumeration ........................................................................................................... 48
4.3.1
Application level ............................................................................................ 48
4.3.2
Implementation level ..................................................................................... 52
4.4 Mode declaration .................................................................................................... 55
4.4.1
Mode declaration group in DaVinci Developer ............................................... 55
4.4.2
Mode service port in BswM configuration ...................................................... 59
4.4.3
Mode request port and mapping .................................................................... 62
4.5 Implementation data type examples ....................................................................... 66
4.5.1
Type reference .............................................................................................. 66
4.5.2
Value ............................................................................................................. 67
5 Additional information ................................................................................................. 69
5.1 Compatibility and conversion .................................................................................. 69
5.2 Measurement and calibration ................................................................................. 70
5.3 Symbols ................................................................................................................. 72
5.4 Data type mapping assistant .................................................................................. 73
2014, Vector Informatik GmbH
Version: 1.1
3 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
5.5 Type emitter ........................................................................................................... 78
6 Glossary and Abbreviations ........................................................................................ 79
6.1 Glossary ................................................................................................................. 79
6.2 Abbreviations ......................................................................................................... 79
7 Contact.......................................................................................................................... 80
Illustrations
Figure 3-1
S/R port interface element .......................................................................... 9
Figure 3-2
S/R port interface element init value ........................................................... 9
Figure 3-3
DaVinci Developer – workspace library ..................................................... 10
Figure 3-4
Application data type categories ............................................................... 10
Figure 3-5
Application data type Value property dialog .............................................. 11
Figure 3-6
Implementation data type categories ........................................................ 12
Figure 3-7
Implementation data type Value property dialog ....................................... 13
Figure 3-8
2 ways of modelling platform independent implementation data types ...... 17
Figure 3-9
Modelling a platform specific implementation data type ............................ 18
Figure 3-10
Platform Types in DaVinci Developer ........................................................ 19
Figure 3-11
Implementation data type referencing a platform type ............................... 19
Figure 3-12
Native declaration: Autosar Standard Type ............................................... 20
Figure 3-13
Native declaration: valid C expression ...................................................... 21
Figure 4-1
New Value application data type ............................................................... 24
Figure 4-2
My_TemperatureType ............................................................................... 25
Figure 4-3
My_TemperatureType_CompuMethod ...................................................... 25
Figure 4-4
Celsius unit ............................................................................................... 26
Figure 4-5
Physical to Internal linear scale ................................................................ 26
Figure 4-6
Physical constraint .................................................................................... 27
Figure 4-7
Type mapping set creation ........................................................................ 28
Figure 4-8
Type mapping set naming ......................................................................... 28
Figure 4-9
Add a data type mapping to a type mapping set ....................................... 29
Figure 4-10
My_TemperatureInterface ......................................................................... 30
Figure 4-11
My_TemperatureElement .......................................................................... 30
Figure 4-12
SWC_Sender modeling ............................................................................ 31
Figure 4-13
SWC_Receiver modeling .......................................................................... 32
Figure 4-14
Connection of My_TemperatureInterface ports ......................................... 33
Figure 4-15
Missing data type mapping error message ............................................... 33
Figure 4-16
Reference a type mapping set in a SWC .................................................. 34
Figure 4-17
My_SpeedType settings ........................................................................... 36
Figure 4-18
New Record application data type ............................................................ 37
Figure 4-19
Record type creation with 2 record elements ............................................ 38
Figure 4-20
New Record implementation data type ..................................................... 39
Figure 4-21
Set a record implementation data type...................................................... 40
Figure 4-22
Record type mapping ................................................................................ 41
Figure 4-23
Sender/receiver port interface with record element ................................... 42
Figure 4-24
Record manual init – part 1 ....................................................................... 43
Figure 4-25
Record manual init – part 2 ....................................................................... 44
Figure 4-26
Record constant creation .......................................................................... 45
Figure 4-27
Referencing a record constant as init value .............................................. 46
Figure 4-28
My_RecordInterface port connection ........................................................ 46
2014, Vector Informatik GmbH
Version: 1.1
4 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
Figure 4-29
My_Enumeration type ............................................................................... 48
Figure 4-30
My_EnumerationType_CompuMethod ...................................................... 49
Figure 4-31
Enumeration text table setting .................................................................. 49
Figure 4-32
Enumeration constraint ............................................................................. 50
Figure 4-33
My_Enumeration mapping to uint8 ........................................................... 50
Figure 4-34
“My_EnumerationInterface” ...................................................................... 50
Figure 4-35
My_EnumerationImplType ........................................................................ 52
Figure 4-36
My_EnumerationImplType_CompuMethod ............................................... 52
Figure 4-37
My_EnumerationImplType_CompuMethod text table ................................ 53
Figure 4-38
My_EnumerationImplInterface .................................................................. 53
Figure 4-39
New mode declaration group .................................................................... 55
Figure 4-40
My_ModeDeclarationGroup ...................................................................... 56
Figure 4-41
My ModePortInterface .............................................................................. 56
Figure 4-42
Mode ports connection ............................................................................. 57
Figure 4-43
Mode port access ..................................................................................... 57
Figure 4-44
BswM configuration .................................................................................. 59
Figure 4-45
BswM import in DaVinci Developer ........................................................... 59
Figure 4-46
Mode declaration group import in DaVinci Developer ............................... 60
Figure 4-47
ComM mode declaration group ................................................................. 60
Figure 4-48
My_ModeDeclarationGroup ...................................................................... 62
Figure 4-49
My_ModeDeclarationGroup_IType ........................................................... 63
Figure 4-50
Mode declaration group mapping.............................................................. 63
Figure 4-51
My_ModeRequestInterface ....................................................................... 64
Figure 4-52
My_ModeRequestPort .............................................................................. 64
Figure 4-53
Type mapping set reference for mode request .......................................... 64
Figure 4-54
New type reference................................................................................... 66
Figure 4-55
Value implementation data type ................................................................ 67
Figure 4-56
My_ImplValue_base base type ................................................................. 68
Figure 4-57
Implementation type constraint ................................................................. 68
Figure 5-1
Info Message #40286 ............................................................................... 69
Figure 5-2
Rte configuration for A2L generation ......................................................... 70
Figure 5-3
A2L generation folder................................................................................ 70
Figure 5-4
Symbol field for implementation data type ................................................ 72
Figure 5-5
Data type mapping assistant opening ....................................................... 73
Figure 5-6
Data type mapping assistant ..................................................................... 73
Figure 5-7
New mapping............................................................................................ 75
Figure 5-8
Existing mapping ...................................................................................... 75
Figure 5-9
Created after new mapping ....................................................................... 76
Figure 5-10
New mapping with implementation data type creation .............................. 76
Figure 5-11
Existing mapping with implementation data type creation ......................... 77
Figure 5-12
Created after new mapping with implementation data type creation ......... 77
2014, Vector Informatik GmbH
Version: 1.1
5 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
1 Introduction
This technical reference aims at presenting Data Type modeling with Vector DaVinci tool
chain in Autosar 4.0.3 context.
2014, Vector Informatik GmbH
Version: 1.1
6 / 80
based on template version 5.1.0

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

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


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


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


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



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


Technical Reference Autosar 4.0 - DataTypes
- Constraint:
It is possible to define constraints at implementation level.
Note
A constraint at implementation level will be used generally to define the valid internal
range.
Figure 3-7 Implementation data type Value property dialog
2014, Vector Informatik GmbH
Version: 1.1
13 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
3.4
Data type mapping
As previously written, application data types must be mapped to implementation data
types. For this purpose data type mapping sets containing data type mappings must be
created. Data type mappings contain two references, one to the application data type and
one to the implementation data type.
In order to let the Rte generator access the right data type mapping for each data
prototype needing a data type mapping, data type mapping sets must be referenced by the
SWCs using the corresponding data prototypes.
Mode declaration groups may also be mapped to implementation data types in
ModeRequestTypeMap contained also in data type mapping sets. The purpose of this
mapping is not the representation of the mode declaration group in the code because the
type used in the code for mode declaration groups is generated automatically by the Rte
generator according to the number of mode declarations: uint8 for 1 to 256 mode
declarations, uint16 for 257 till 65536 mode declarations, and so on...
The purpose of a ModeRequestTypeMap is to be able to create mode request ports. As
specified by Autosar a component that requests mode changes to a mode master shall
implement a sender/receiver P-Port on which the requests will be sent. The corresponding
port interface’s data element shall be typed by an implementation data type referencing a
compu method containing an enumeration of the corresponding modes. That
implementation data type shall be mapped to the corresponding mode declaration group.
Examples are presented in chapter 4.
2014, Vector Informatik GmbH
Version: 1.1
14 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
3.5
Platform types
3.5.1
Definitions
3.5.1.1
Autosar Standard Types
Autosar Standard Types are the following symbols used in C code:
> uint8
> uint16
> uint32
> sint8
> sint16
> sint32
> boolean
> float
> float32
3.5.1.2
Platform Types
Platform types are implementation data types which have an Autosar Standard Type as
name.
Platform types, as subset of implementation data types, are part of the model.
3.5.1.3
Valid C expression
A valid C expression is a C type optionally combined to a C size qualifier and/or a C sign
qualifier.
> C types are: char, int, float, double, void
> C size qualifiers are: short, long
> C sign qualifiers are: signed, unsigned
2014, Vector Informatik GmbH
Version: 1.1
15 / 80
based on template version 5.1.0

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


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


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


Technical Reference Autosar 4.0 - DataTypes
Figure 3-10 Platform Types in DaVinci Developer
According to Autosar it is advised to do the following:
 Use directly Platform Types as implementation data types.
 Create an own implementation data type of category “Type Reference” referencing a
Platform Type:
Creating MyImplementationDataType as Type Reference pointing on uint8 (see Figure
3-11) 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)
In Rte_Type.h:
# define Rte_TypeDef_My_RecordImplementationType
typedef struct
{
sint16 TemperatureImplementationRecordElement;
uint16 SpeedImplementationRecordElement;
} My_RecordImplementationType;
In Rte.c:
CONST(My_RecordImplementationType, RTE_CONST) Rte_C_My_RecordImplementationType_0 = {
40, 0U
};
CONST(My_RecordImplementationType, RTE_CONST) Rte_My_RecordConstant = {
40, 0U
};
The record data element is typed by My_RecordImplementationType.
The record type has 2 elements, TemperatureImplementationRecordElement of type
sint16 and SpeedImplementationRecordElement of type uint16.
Two constants are generated for the init values: Rte_My_RecordConstant corresponding
to the constant created in DaVinci Developer and Rte_C_MyRecordImplementationType_0
corresponding to the init value set manually.
2014, Vector Informatik GmbH
Version: 1.1
47 / 80
based on template version 5.1.0

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



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



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


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



Technical Reference Autosar 4.0 - DataTypes
Figure 4-37 My_EnumerationImplType_CompuMethod text table
 A sender/receiver port interface “My_EnumerationImplInterface” is created. It contains
one data element of type “My_EnumerationImplType“ (see Figure 4-38).
Figure 4-38 My_EnumerationImplInterface
 A P-Port is created on the SWC_Sender with write access to the data element in the
SWC_SenderRunnable, an R-Port is created on the SWC_Receiver with read access
to the data element in the SWC_ReceiverRunnable, init values are specified and both
ports are connected.
 The system description resulting from the configuration done in DaVinci Developer is
imported in DaVinci Configurator Pro. There the Rte generation and the SWC
generation are performed.
2014, Vector Informatik GmbH
Version: 1.1
53 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
The following code is generated:
In SWC_Sender.c:
Std_ReturnType
Rte_Write_My_EnumerationImplInterface_My_EnumerationImplElement(My_EnumerationImplType data)
* Enumeration Types:
* ==================
* My_EnumerationImplType: Enumeration of integer in interval [0...255] with enumerators
* Text_00 (0U)
* Text_01 (1U)
* Text_02 (2U)
In SWC_Receiver.c:
Std_ReturnType Rte_Read_My_EnumerationImplInterface_My_EnumerationImplElement(My_EnumerationImplType
*data)
* Enumeration Types:
* ==================
* My_EnumerationImplType: Enumeration of integer in interval [0...255] with enumerators
* Text_00 (0U)
* Text_01 (1U)
* Text_02 (2U)
In Rte_SWC_Sender_Type.h and Rte_SWC_Receiver_Type.h:
# define My_EnumerationType_LowerLimit (0U)
# define My_EnumerationType_UpperLimit (2U)
# ifndef Text_00
# define Text_00 (0U)
# endif
# ifndef Text_01
# define Text_01 (1U)
# endif
# ifndef Text_02
# define Text_02 (2U)
# endif
In Rte_Type.h:
# define Rte_TypeDef_My_EnumerationImplType
typedef uint8 My_EnumerationImplType;
The data element is typed by My_EnumerationImplType which is defined as uint8.
Each enumeration text is defined with the corresponding uint8 value
2014, Vector Informatik GmbH
Version: 1.1
54 / 80
based on template version 5.1.0


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


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




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



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


Technical Reference Autosar 4.0 - DataTypes
Figure 4-46 Mode declaration group import in DaVinci Developer
Figure 4-47 ComM mode declaration group
This configuration gives then the following generated code:
In SWC_A.c:
Rte_ModeType_ComMMode
Rte_Mode_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode(void)
//Modes of Rte_ModeType_ComMMode:
// - RTE_MODE_ComMMode_COMM_FULL_COMMUNICATION
// - RTE_MODE_ComMMode_COMM_NO_COMMUNICATION
// - RTE_MODE_ComMMode_COMM_SILENT_COMMUNICATION
// - RTE_TRANSITION_ComMMode
In Rte_SWC_A.h:
//Buffers for Mode Management
extern
VAR(Rte_ModeType_ComMMode,
RTE_VAR_NOINIT)
Rte_ModeMachine_BswM_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode
;
In Rte.c:
/* mode management initialization part 1 */
Rte_ModeMachine_BswM_ModeSwitch_Interfaces_ComM_CurrentMode_ComMMode_currentMode
= RTE_MODE_ComMMode_COMM_NO_COMMUNICATION;
2014, Vector Informatik GmbH
Version: 1.1
60 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
In Rte_Type.h:
//define Rte_TypeDef_ComM_ModeType
typedef uint8 ComM_ModeType;
//Definitions for Mode Management
typedef uint8 Rte_ModeType_ComMMode;
# define RTE_MODE_ComMMode_COMM_FULL_COMMUNICATION (0U)
# define RTE_MODE_ComMMode_COMM_NO_COMMUNICATION (1U)
# define RTE_MODE_ComMMode_COMM_SILENT_COMMUNICATION (2U)
# define RTE_TRANSITION_ComMMode (3U)
The mode declaration group Com_ModeType is typed by uint8.
The mode declarations are available as defines and their uint8 value is given in the
alphabetical order.
2014, Vector Informatik GmbH
Version: 1.1
61 / 80
based on template version 5.1.0

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



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




Technical Reference Autosar 4.0 - DataTypes
Figure 4-51 My_ModeRequestInterface
 A service P-Port prototype referencing this port interface is created on the SWC
(Figure 4-52).
Figure 4-52 My_ModeRequestPort
 The type mapping set is referenced by the SWC (Figure 4-53).
Figure 4-53 Type mapping set reference for mode request
2014, Vector Informatik GmbH
Version: 1.1
64 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
 A runnable of the SWC shall have write access on the created port.
 In DaVinci Configurator, the corresponding mode request port on BswM can be
created and mapped to the SWC port.
 The generated code provides the following for the SWC:
Type and enumeration definition:
* Enumeration Types:
* ==================
* My_ModeDeclarationGroup_IType: Enumeration of integer in interval [0...255] with
enumerators
* My_A_Mode (0U)
* My_B_Mode (1U)
* My_C_Mode (2U)
* My_D_Mode (3U)
Mode request API for the SWC:
Std_ReturnType Rte_Write_My_ModeRequestPort_My_ModeRequest(My_ModeDeclarationGroup_IType
data)
2014, Vector Informatik GmbH
Version: 1.1
65 / 80
based on template version 5.1.0

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

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


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

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



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


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


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


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

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


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




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






Technical Reference Autosar 4.0 - DataTypes
Figure 5-11 Existing mapping with implementation data type creation
Figure 5-12 Created after new mapping with implementation data type creation
Note
The assistant needs information from the application data type constraints and/or
compu methods to be able to map it. In case this information is not sufficient, then the
assistant will not be able to map automatically and the state will be “no mapping
possible”:
2014, Vector Informatik GmbH
Version: 1.1
77 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
5.5
Type emitter
As defined by Autosar implementation data types have a “Type emitter” parameter. It
defines the entity that shall provide the code definition of the implementation data type.
If Type emitter is set to “RTE” or is empty, the RTE shall generate a typedef for the
implementation data type according to the native declaration of the referenced base type
(category Value) or according to the referenced implementation data type (category Type
Reference).
If Type emitter has any other value, then the RTE does not generate the corresponding
typedef. It is here intended that the definition of that implementation data type will be
provided by another entity.
2014, Vector Informatik GmbH
Version: 1.1
78 / 80
based on template version 5.1.0
Technical Reference Autosar 4.0 - DataTypes
6 Glossary and Abbreviations
6.1
Glossary
Term
Description
6.2
Abbreviations
Abbreviation
Description
SWC
Software Component
BswM
Basic Software Manager
ComM
Communication Manager
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
Document Outline
- 1 Introduction
- 2 Data Types and Data Prototypes
- 3 Design of data prototypes in DaVinci tool chain
- 4 Design examples
- 5 Additional information
- 6 Glossary and Abbreviations
- 7 Contact
3.18 - TechnicalReference_EcuConfigurationFiles
3.19 - TechnicalReference_EcuConfigurationFiles_ind
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
3.20 - TechnicalReference_EcuConfigurationFiless

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

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

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

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


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

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

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

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

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

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

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


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

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


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



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


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





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

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

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

ECU-C File Handling Technical Reference
4.3.2
Parameters
SchM module configuration
Parameter
Read/Write
SchMMainFunctionMapping/
r
SchMMainFunctionSymbol
r
SchMBswActivationOffset
r
SchMMappedToTask
r
SchMPositionInTask
r
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
ComSignal/
w
ShortName
(r)
ComDataInvalidAction
w
ComInvalidNotification
w
ComSignalDataInvalidValue
w
SystemTemplateSystemSignalRef
(r)/w
ComSignalInitValue
w
ComErrorNotification
w
ComNotification
w
ComTimeoutNotification
w
ComTimeoutFactor
w
ComSignalType
w
ComFilter/
ComFilterAlgorithm
w
ComFilterMask
w
ComSignalGroup/
w
ShortName
(r)
ComDataInvalidAction
w
ComErrorNotification
w
ComInvalidNotification
w
ComNotification
w
ComTimeoutFactor
w
ComTimeoutNotification
w
SystemTemplateSignalGroupRef
(r)/w
2014, Vector Informatik GmbH
Version: 1.13
21 / 34

ECU-C File Handling Technical Reference
ComGroupSignal/
(r)/w
ShortName
(r)
ComSignalDataInvalidValue
w
ComSignalInitValue
w
ComSignalType
w
SystemTemplateSystemSignalRef
(r)/w
ComFilter/
ComFilterAlgorithm
w
ComFilterMask
w
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

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

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

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

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

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


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


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

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

ECU-C File Handling Technical Reference
6 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector-informatik.com
2014, Vector Informatik GmbH
Version: 1.13
34 / 34
3.21 - TechnicalReference_UserDefinedAttributeExport
3.22 - TechnicalReference_UserDefinedAttributeExport_ind
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
3.23 - TechnicalReference_UserDefinedAttributeExports

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

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

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


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


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


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

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

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

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

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

User-defined attribute XML-export Technical Reference
6 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com
2012, Vector Informatik GmbH
Version: 1.3
3.24 - UserManual_DataImport
3.25 - UserManual_DataImport_ind
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
3.26 - UserManual_DataImports

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

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

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

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

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

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

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

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

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

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

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

User Manual Data Import
Runnable Entities
Existing Runnable Entities are merged as follows: the Symbol and Can Be
Invoked Concurrently is not changed, the Trigger list and Port Access lists are
merged.
Missing Runnable Entities are created
Exclusive Areas, Inter-Runnable Variables and Calibration Parameters
Existing objects are overwritten
Missing objects are added
Per-Instance Memory
Existing PIMs are overwritten
Missing PIMs are added
Obsolete Diagnostic PIMs** are deleted
Note: This special import function does not consider the import mode preset attributes (see
chapter 4.2).
*) Diagnostic Port Prototypes are Port Prototypes, which contain an attribute with a value
other than the default for an attribute definition, which contains “PDM_ID” in its name
**) Diagnostic PIMs are PIMs, which contain an attribute with a value other than the default
for an attribute definition, which contains “PDM_ID” in its name
6 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector-informatik.com
2011, Vector Informatik GmbH
Version: 2.0
3.27 - UserManual_Working_with_DCF
3.28 - UserManual_Working_with_DCF_ind
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
3.29 - UserManual_Working_with_DCFs

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

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

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

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

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

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

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

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


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


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





User Manual Working with DCF
5 Working with DCF
5.1 Creating a new DCF
Select File | New
workspace… or use the
shortcut .
Select “DaVinci Configuration
Files (*.dcf)” as file type.
Browse for a suitable folder
and set a file name for the
DCF file.
You may now work as usual in
with DaVinci Developer to
define new objects.
To save the data select
File | Save Workspace… or
use the shortcut
.
Please observe the following conditions, which apply to the folder of a DCF file:
The folder, which contains the DCF file, must not contain other DCF files
Within the folder of the DCF file and within any sub-folder, the following file types are
“reserved” for DaVinci
*.arxml
*.dcf
*.dcb
2012, Vector Informatik GmbH
Version: 1.6




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



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



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

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



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



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

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


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




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



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





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





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




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





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



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

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

User Manual Working with DCF
9 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com
2012, Vector Informatik GmbH
Version: 1.6
3.30 - Welcome
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.
3.31 -
DaVinci Developer 3.13 Installation Guide
Copyright (c) 2016 Vector Informatik GmbH. All rights reserved.
Installation of DaVinci Developer
Compatibility
A correct configuration of the MICROSAR RTE is only possible if you use the dedicated version of the DaVinci Developer. Please check the MICROSAR Rte Compatibility Matrix to find the DaVinci Developer version you need.
Please Note: Your licensed DaVinci Developer version defines the highest version you are able to use. Depending on the specific basic software version of a project you might need to use a tool version which is lower than your actual licence.
External Components
In order to work with DaVinci Developer some shared external components have to be installed first. Please install the latest DaVinci External Components Setup from the Vector Download Center
Setup Program
Start the DaVinci setup program Setup.exe and follow the setup steps.
Please note: You must have administrator rights to install DaVinci Developer.
Under some circumstances the InstallShield setup can't be started on a network drive. To ensure proper installation please copy the full installation setup into a temporary directory on a local drive and execute the Setup.exe from this directory.
System modifications performed by DaVinci Developer setup
Shared components
DaVinci External Components Setup will install the following shared runtime components:
- Microsoft Visual C++ Runtime
- Microsoft .NET Framework 2.0 SP2
- Microsoft .NET Framework 4
- 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.13") 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.13" 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.
Additional Information
Vector Informatik GmbH Support
- Our business hours are Monday to Friday from 9:00 am to 5:00 pm (CET) - Phone: +49.711.80670.200 
 Fax: +49.711.80670.111
 E-Mail: support@vector.com
 Online Report Form: http://vector.com/support
3.32 -
DaVinci Developer Release Notes
Copyright (c) 2017 Vector Informatik GmbH. All rights reserved.
Table of contents
DaVinci Developer Version 3.13 (SP4)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.Due to an architectural enhancement in the ARXML processing the performance and memory usage differs from the previous Service-Pack.Depending on the use-case and data structures this can also result in a slower loading and saving performance or an increased memory usage, this will be optimized again with upcomingversions
Tool features
- Map&Curve: Support of Array Implementation Data Types with shared Axis has been added
Usability enhancements
- TP transmitted Signals mapped to unqueued Data-Elements are now only reported as Warning and not as Error
- Consistency check of NvM service needs now reports as Warning and not as Error
- Platform development assignments for component types, runnables, and ports can now be done with multi-select properties dialog
Fixed issues
- Explicit platform development function annotations defined with DaVinci Developer were not visible in DaVinci Configurator
- Compatibility check of constants wasn't correct if both ConstValueSpecs were of type application
- DCF workspace of a DPA project contained obsolete proprietary communication objects that result in duplicate short-names errors
- When exporting an ApplicationDataType array the DynamicArraySizeProfile: 'None' was falsely exported
- Special import (Overwrite import mode preset) aborts with the error "The transformation of this item is not supported" if any component type is specified in the import file
- When using Data-Transformation an obsolete check throws #40402 "Multiple operation mappings of network signal" if a signal was multiply mapped to a client ECU delegation port
- If the workspace referenced a platform development function file the project update aborts with (FatalError: 0xC0500001 - Reason: Could not load the workspace)
- The inplace attribute wasn't shown when showing the End-To-End transformation technology (e.g. from Signal large data)
- The ECU communication wasn't updated correctly, if a signal was moved from one PDU to another PDU
- The predefined application and service port interface files contained objects with identical UUIDs
- The transformer settings at a port prototype Com-Spec were lost
- The category of a AppValueSpecification wasn't correctly imported/exported which causes data loss on roundtrip
- The consistency check #40314 and #40316 referenced obsolete AUTOSAR constraints
- If the range of a CompuScale wasn't set (Category LINEAR or SCALE_LINEAR) it was always imported as default with 0..255
- Project update aborted with error: "Unable to find ECU-Project for update. (code 0xC0500012)" if the ECU-Project has a different name than the DPA Project
- Project update aborted with error: "Internal exception occurred: Object reference not set to an instance of an object. (code 0x80004003)" if substitute missing objects was used and the ECU Top-Level Composition wasn't part of the input files
- The import of a tx "Ack Only" runnable data access was invalid and results in check #30058 "Incompatible runnable data access detected."
- Texttable couldn't be mapped on a boolean implementation type and results in consistency check #40338 "Inconsistent data type mappings"
- Creating a new Application Constant from within the Reference Constant dialog resulted in a wrong created data type
- SWC import throws error "could not access element" if the service dependency (e.g. a diagnostic control IO need) referenced another element (e.g. a diagnostic event need).
- Additionally merged issues from service packs of previous releases:
- ARXML import removed a Runnable Data Access if a referencing Variable Data Prototype was renamed in the imported ARXML file
- Description for nested data types was incorrectly stored when saving a workspace.
- ARXML import crashed if an array data type referenced an undefined base type
- An invalid Port Terminator was not removed by the workspace check
- If a Port Interface had several Data Elements, the multi-edit function for Com-Spec settings on a SWC was not working
- DCF workspace with a single tx ack only runnable access couldn't be opened anymore
- DCF workspace with an unnamed runnable mode switch point couldn't be opened anymore
DaVinci Developer Version 3.13 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.Due to an architectural enhancement in the ARXML processing the performance and memory usage differs from the previous Service-Pack.Depending on the use-case and data structures this can also result in a slower loading and saving performance or an increased memory usage, this will be optimized again with upcomingversions
Tool features
- AUTOSAR 4.3.0 is now supported.
- Calibration element prototype mappings are now supported
- SwcToECUMapping is now exported as part of the SystemElement
- Category Tag for ApplicationValueSpecifications is now exported
- Top-down definition of DTCStatusChangedNotification service need is now supported
- The parameter 'TransformationErrorHandling' is now supported in the Port-API options of Port-Prototypes
Usability enhancements
- 'Graphic settings' are now accessible via the context menu
- To reduce the memory consumption of signals not actually received/sent by the ECU Instance are now ignored during ARXML import
- The specific Transformer Type is now displayed in the data mapping view and signal selection dialog
- CompuMethod consistency check has been improved to check for unique identifiers and multiple identical ranges
- Compatibility check for constants has been extended for to show more detailed information
- Additional check was implemented to ensure that an axis, that is referenced by a characteristic table (CT), is used elsewhere within the corresponding software component
- When changing the CompuMethod Category in the GUI to a non-TextTable the tool now queries if the defined enumerators should be removed
- Find unused data types was very slow on a large amount of objects
Fixed issues
- Depending on the FlexNet environment the application may hanged-up at startup during license query
- Create Port Prototypes created a Base-Type with invalid Native Declaration 'int16' instead of 'sint16'
- End-to-End Transformer settings at receiver ComSpec were not editable when using in modal properties dialog
- 'Generate Contract Phase / Component Implementation Templates' aborted if there are model consistency warnings
- Existing wait-points were not removed when changing the port access to none
- When creating an implementation data type of category array, the attribute 'size handling' was not persisted
- Compu-Scales were not correctly updated if they didn't specify symbol, label or constant
- Import of Variant Clusters is now rejected with a specific error message since this is not supported
- Consistency message #40405 'CompuScale without label' was falsely shown if the Compu-Scale defined a symbol and/or constant but not a label
- NvM Port Assignment disappeared from the list after renaming but it still existed
- Create Port from Signal didn't consider CompuMethod to create arrays and records
- Assignment of a NvMBlockNeed to a PIM didn't remove existing assignments when using the PIM-page
- When the NvBlockNeed-Page was opened within a standalone dialog, the action bitmap-buttons didn't appear
- Exporting a NVMBlockNeed had duplicated the port assignment
- Changing the service need attribute 'Cycling writing period' is only saved if another attribute had been changed too
- Wrong service need type had been created for DcmDiagIOControlNeed, DcmDiagSecurityNeed, DltUserNeed
- Multiply used RecordLayout-Annotations were not detected by the consistency check
- Existing service needs were falsely reset to default during ARXML import of a Nv software component
- Since AUTOSAR version 4.2.2 double underscores can be used in Short-Names but DaVinci DEV didn't accepted this in GUI and ARXML import/export
DaVinci Developer Version 3.13 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Preparation for upcoming AUTOSAR 4.3.0 schema version files. Currently no new features are supported.
- Support for 64 bit COM signals according to AUTOSAR 4.2.2 has been added
Usability enhancements
- Additional consistency check has been implemented to ensure that different ranges of a Compu-Method don't overlap
- Additionally merged usability enhancements from service packs of previous releases:
- Create port with data-type from signal now suppresses transformed signals
- Delete of End-to-End connections with multi-select is now supported
- ArrayElement-ReferenceName is now configurable
Fixed issues
- Data type mapping check didn't support integer data types which require more than 32 bit
- DaVinci CFG5 threw "unsupported merge/communication scenario" error message if data mapping was done in CFG5 at atomic ports and the same signal was mapped to the same port for different variants
- Consistency check for application data types that references compu methods of type "BitfieldTextTable" was wrong
- Bitfield dialog showed "out of range" on correctly defined bitfield values
- Rte code generation failed with error 40170 "Multiple mappings for network signal" if the same data mapping was done in DaVinci CFG5 at atomic ports of different component prototypes
- References to record elements stored in external files were not resolved when loading a workspace
- Compu method could be deleted but was used within the ISignal network representation
- Project update aborted if an E2E protection with same name is defined in different E2E protection sets and the E2E protection specifies an E2E ISignal IPDU
- Additionally merged issues from service packs of previous releases:
- Consistency check 40454 didn't consider array element mapping according to AUTOSAR Constr_1004
- Delegation ports with several data mappings for different variants weren't supported
- Communication and data mapping was lost after import of an ECU-Extract having several clusters with the same name
- "Adapt structure of record type" function created non-matching init value for nested complex data-types
- AR3 to AR4 workspace conversion showed the error message 40338 inconsistent data type mappings when using real data-types
- Loading a workspace with external DCF references failed with message "Item with name is read-only" if the loaded DCF referenced another DCF with custom generic attributes 
- Existing Type-Reference couldn't be selected as Inter-Runnable-Variable data-type
- ARXML export duplicated the data mapping if the signal was mapped and the signal was part of a signal group
- Constant reference wasn't imported correctly for calibration parameters with 'per instance' scope
- Create port from signal group didn't consider the variant assignment
- The separate variant assignment for group signal mappings wasn't deactivated if the signal group is already mapped
DaVinci Developer Version 3.13 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Various Diff/Merge extensions to support sub-elements e.g. internal behavior
- Software Component Prototypes are now allowed to have the same name in different compositions
- Variant I-Signal groups with the same triggering and System-Signal group are now supported
Usability enhancements
- DaVinciDEV.exe command line parameters can now be displayed using /help switch
- Additionally merged usability enhancements from service packs of previous releases:
- Tool version check is now skipped for workspaces without having a ECU-Project
- Consistency check 40269 has be enhanced to accept a data length of 0 for Intra-ECU End-to-End Protection
- The ImportModePreset is now respected when importing the DataMapping so that the mapping of a Delegation-Port with 'keep' will not be deleted
Fixed issues
- The "Uses Tx Acknowledge" check box value couldn't be changed
- Additionally merged issues from service packs of previous releases:
- Signal's init/invalid value was always "" in the properties dialog 
- Option 'delete unreferenced files' deleted files which were still in use if the filename only differs in character case
- Data-Mapping couldn't handle mapped ports without port-interfaces
- Connections were deleted during ARXML import even if the import mode preset should avoid that
- The import mode preset generic attribute definition of new workspaces was wrong if they were created through DaVinci Configurator 5
- Consistency message 40368 "Inconsistent NvM block needs (RAM Block Status Control)" was shown although the model is correct
- Inter-Runnable-Variables and Port Accesses weren't merged correctly which lead into multiple definitions
- Create port from signal didn't create correct init values in all cases
- Init value constant contained duplicate record elements after merge
- Port interfaces were are not updated correctly when overwriting a sender receiver port interface with a mode switch interface (or vice versa)
DaVinci Developer Version 3.13
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Connections between NvRAM Sender/Receiver ports and application Sender/Receiver ports are supported now
- Derivation of transformer configuration from System-Extract with Xf Technology for E2E, ComBased, and SOME/IP has been added
- Compatibility with Windows 10 has been approved
Usability enhancements
- Enhanced workspace check options for incomplete design/open ports.
- The End-to-End Connection view now supports deletion of connections with multi-select
Fixed issues
- Diagnostic import didn't update Calibration Port init values
- ECU Project couldn't be updated anymore if its name was not a valid AUTOSAR identifier
DaVinci Developer Version 3.12 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Various Diff/Merge extensions to support sub-elements e.g. internal behavior
- Software Component Prototypes are now allowed to have the same name in different compositions
Usability enhancements
- Create port with data-type from signal now suppresses transformed signals
- Delete of End-to-End connections with multi-select is now supported
- ArrayElement-ReferenceName is now configurable
- Additionally merged usability enhancements from service packs of previous releases:
- Tool version check is now skipped for workspaces without having a ECU-Project
- Consistency check 40269 has be enhanced to accept a data length of 0 for Intra-ECU End-to-End Protection
- The ImportModePreset is now respected when importing the DataMapping so that the mapping of a Delegation-Port with 'keep' will not be deleted
Fixed issues
- Consistency check 40454 didn't consider array element mapping according to AUTOSAR Constr_1004
- Delegation ports with several data mappings for different variants weren't supported
- Communication and data mapping was lost after import of an ECU-Extract having several clusters with the same name
- "Adapt structure of record type" function created non-matching init value for nested complex data-types
- AR3 to AR4 workspace conversion showed the error message 40338 inconsistent data type mappings when using real data-types
- Loading a workspace with external DCF references failed with message "Item with name is read-only" if the loaded DCF referenced another DCF with custom generic attributes 
- Existing Type-Reference couldn't be selected as Inter-Runnable-Variable data-type
- ARXML export duplicated the data mapping if the signal was mapped and the signal was part of a signal group
- Constant reference wasn't imported correctly for calibration parameters with 'per instance' scope
- Create port from signal group didn't consider the variant assignment
- The separate variant assignment for group signal mappings wasn't deactivated if the signal group is already mapped
- Additionally merged issues from service packs of previous releases:
- Signal's init/invalid value was always "" in the properties dialog 
- Option 'delete unreferenced files' deleted files which were still in use if the filename only differs in character case
- Data-Mapping couldn't handle mapped ports without port-interfaces
- Connections were deleted during ARXML import even if the import mode preset should avoid that
- The import mode preset generic attribute definition of new workspaces was wrong if they were created through DaVinci Configurator 5
- Consistency message 40368 "Inconsistent NvM block needs (RAM Block Status Control)" was shown although the model is correct
- When importing a Calibration Software Component the constant-reference in the role of an init-value wasn't set
- Contract phase generation couldn't be used at the ECU-Project
- Crash during SWC check on runnable data accesses by value has been fixed
- Inter-Runnable-Variables and Port Accesses weren't merged correctly which lead into multiple definitions
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- In some cases a double click on a .dcf file started the wrong DaVinci Developer version
- Create port from signal didn't create correct init values in all cases
- Saving a workspace aborted with "invalid argument" error if the ECU-Extract contained incorrect E2E connections
- A component type DCF file accidently contained data constr elements
- Init value constant contained duplicate record elements after merge
- GUI crashed when calling "Show in other views" on a found object
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Loading a DCF workspace crashed if the .dcf file contained an absolute file reference with more than 260 characters
- Port interfaces were are not updated correctly when overwriting a sender receiver port interface with a mode switch interface (or vice versa)
- Deleting a runnable caused an error during workspace saving if a Calibration Parameter or Per-Instance Memory exists at the software component
DaVinci Developer Version 3.12 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Mapping of CharacteristicTable and Axis application data types to the corresponding Record and Array implementation data types has been added
- Service need support has been completed according to AUTOSAR 4.2.2
- Find function for objects with duplicate UUIDs has been added
Usability enhancements
- Interaction and error handling between DaVinci Configurator and DaVinci Developer has been enhanced to get more information during project update
- Additionally merged usability enhancements from service packs of previous releases:
- Search of unused Data-Types has been split to allow separate search for Application and Implementation Data-Types
- Data-Type mapping can be optionally ignored for easier finding of unused Application/Implementation types
- The range setting of 0..0 for CompuScales which didn't define an upper/lower limit is now supported as optional in ARXML export
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- No error was returned to DaVinci Configurator if a project update fails due to an invalid ARXML file
- Consistency check 40284 concerning multiple used names appeared without further name information
- A constant's unit wasn't imported if a communication specification contained an application value specification with a unit reference
- Unmap of a variant data-mapping crashed if it have been previously mapped after saving the workspace.
- Additionally merged issues from service packs of previous releases:
- Port-Interface was listed as unused even if a blueprint port prototype or an interface mapping existed
- Object usage on a port interfaces didn't show the referencing port interface mapping set
- It was unable to define a init value at the ComSpec because the properties button wasn't visible
- Crash during SWC check on runnable data accesses by value has been fixed
- Error message during workspace saving leaded into a crash if the option "Delete unreferenced files from DCF Workspace" was set
- Invalid value of a implementation record couldn't be set if the dialog changes weren't applied immediately
- Import didn't not support the merge of multi-mapping of NvBlockDescriptors
- Renaming of End-to-End protections could cause problems during later updates because the End-to-End protections couldn't be found anymore
- Compatibility of Application Value and Constant Reference wasn't checked
- Data-Type element information wasn't stored correctly at the root data type and vice versa
- The exported or saved component type file didn't contained all runnables
- Multiple System-Mappings (e.g. one for data mappings and another one for pnc mappings) couldn't be imported correctly.
- Loading a workspace was aborted with a NullReferenceException if the project contained multiple identical data mappings with unresolvable references
- ARXML import didn't succeed due to an endless loop if the ARXML contained array definitions with a huge array size
- Application ports couldn't be assigned anymore at the RoleBasedPortAssignments
- Mode Declaration Value range wasn't checked and the value was set to 0
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Function "Replace legacy data types" wasn't executed if LibraryBrowser had the focus
- Wrong unused item was deleted if item with the same name existed in different packages
- Physical to internal compu scales weren't displayed and were deleted when leaving the dialog
- The data transformation flag of a signal couldn't be set due to a read-only checkbox in the dialog
- Bitfields greater than 31 bits weren't handles correctly in consistency check and dialog
- Offset of End-to-End Protection profile 5 wasn't editable
- Signal group dialog accidently allows editing the signal group name and group signal set
- Create port prototype threw an "Invalid pointer" exception if signals of a signal group didn't have a base-type defined
- ARXML export wasn't possible with multi selection of Port Blueprints or Blueprint Mappings Sets
- Consistency check 40439 didn't reflect AUTOSAR constr_1295 correctly
- Crash during SWC check on runnable data accesses by value has been fixed
- Contract phase generation couldn't be used at the ECU-Project
- When using the "Propagate Alive Timeout" function a wrong value was set after loading the value from the communication extract
- Multi-select unmap of data mapping didn't work for complex data elements
- Renaming a package didn't work correctly for DCF workspaces
- Data-mapping of atomic ports lead to "Unsupported communication pattern" errors because create ECU-Delegation port didn't consider new connections
- Create Port Prototypes didn't reference newly created global constants
- Constant References could be created without a destination constant
- Invalid mode accesses are created while importing an AUTOSAR3 file with P-Ports into an AUTOSAR4 workspace
- Rte generator threw an error "[Internal Error] RTE - Could not read GenAPI data" if an argument order index of an Operation-Prototype wasn't unique
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.12 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Support of Characteristic Table (Curve, Map, Cuboid) and COM_AXIS application data types has been added
Usability enhancements
- The consistency check 40043 "Missing init values for open ports" is now optional and can be disabled through a workspace setting
- The consistency check 40286 "Multiple usage of the same name" is now optional and can be disabled through a workspace setting
- Updating a project or saving a workspace took very long if many complex data mappings were defined
- Additionally merged usability enhancements from service packs of previous releases:
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- A signal's data transformation flag was falsely set during creating a data mapping
- Formula-Expression of composite constant values were not converted to a valid numeric value
- Consistency check 40439 didn't reflect AUTOSAR constr_1295 correctly
- Additionally merged issues from service packs of previous releases:
- Multi-select unmap of data mapping didn't work for complex data elements
- Renaming a package didn't work correctly for DCF workspaces
- Data-mapping of atomic ports lead to "Unsupported communication pattern" errors because create ECU-Delegation port didn't consider new connections
- Create Port Prototypes didn't reference newly created global constants
- Constant References could be created without a destination constant
- Invalid mode accesses are created while importing an AUTOSAR3 file with P-Ports into an AUTOSAR4 workspace
- Rte generator threw an error "[Internal Error] RTE - Could not read GenAPI data" if an argument order index of an Operation-Prototype wasn't unique
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.12
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- AUTOSAR schema 4.2.2 is now supported
- Variable array size handling has been adapted to AUTOSAR 4.2.2 specification
- The "Activation Reasons" can now be specified at the runnables and assigned to a trigger
- The port interface mapping now supports sub-element mapping for Rx-Group Signals
Usability enhancements
- An additional check has been implemented to ensure that the compu-method category of implementation data types is either BITFIELD_TEXTTABLE or TEXTTABLE
Fixed issues
- It wasn't possible to map a leaf data element of a complex data element to a group signal if the complex data element itself contained one or more complex data elements.
- Data mapping contained invalid references to elements of multi-dimensional arrays if a signal group and its group signals are mapped to a multi-dimensional array.
- Installer text was truncated if the setup process has been interrupted manually before completion
- Data types in AUTOSAR3 format loosed their compu-method during import into an AUTOSAR 4 workspace.
DaVinci Developer Version 3.11 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Various Diff/Merge extensions to support sub-elements e.g. internal behavior
- Software Component Prototypes are now allowed to have the same name in different compositions
Usability enhancements
- Tool version check is now skipped for workspaces without having a ECU-Project
- Additionally merged usability enhancements from service packs of previous releases:
- Consistency check 40269 has be enhanced to accept a data length of 0 for Intra-ECU End-to-End Protection
- The ImportModePreset is now respected when importing the DataMapping so that the mapping of a Delegation-Port with 'keep' will not be deleted
Fixed issues
- Signal's init/invalid value was always "" in the properties dialog 
- Option 'delete unreferenced files' deleted files which were still in use if the filename only differs in character case
- Data-Mapping couldn't handle mapped ports without port-interfaces
- Connections were deleted during ARXML import even if the import mode preset should avoid that
- The import mode preset generic attribute definition of new workspaces was wrong if they were created through DaVinci Configurator 5
- Consistency message 40368 "Inconsistent NvM block needs (RAM Block Status Control)" was shown although the model is correct
- Additionally merged issues from service packs of previous releases:
- When importing a Calibration Software Component the constant-reference in the role of an init-value wasn't set
- Contract phase generation couldn't be used at the ECU-Project
- Crash during SWC check on runnable data accesses by value has been fixed
- Inter-Runnable-Variables and Port Accesses weren't merged correctly which lead into multiple definitions
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- In some cases a double click on a .dcf file started the wrong DaVinci Developer version
- Create port from signal didn't create correct init values in all cases
- Saving a workspace aborted with "invalid argument" error if the ECU-Extract contained incorrect E2E connections
- A component type DCF file accidently contained data constr elements
- Init value constant contained duplicate record elements after merge
- GUI crashed when calling "Show in other views" on a found object
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Loading a DCF workspace crashed if the .dcf file contained an absolute file reference with more than 260 characters
- Port interfaces were are not updated correctly when overwriting a sender receiver port interface with a mode switch interface (or vice versa)
- Deleting a runnable caused an error during workspace saving if a Calibration Parameter or Per-Instance Memory exists at the software component
DaVinci Developer Version 3.11 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Find function for objects with duplicate UUIDs has been added
Usability enhancements
- Search of unused Data-Types has been split to allow separate search for Application and Implementation Data-Types
- Data-Type mapping can be optionally ignored for easier finding of unused Application/Implementation types
- Additionally merged usability enhancements from service packs of previous releases:
- The range setting of 0..0 for CompuScales which didn't define an upper/lower limit is now supported as optional in ARXML export
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- Port-Interface was listed as unused even if a blueprint port prototype or an interface mapping existed
- Object usage on a port interfaces didn't show the referencing port interface mapping set
- It was unable to define a init value at the ComSpec because the properties button wasn't visible
- Crash during SWC check on runnable data accesses by value has been fixed
- Error message during workspace saving leaded into a crash if the option "Delete unreferenced files from DCF Workspace" was set
- Invalid value of a implementation record couldn't be set if the dialog changes weren't applied immediately
- Additionally merged issues from service packs of previous releases:
- Import didn't not support the merge of multi-mapping of NvBlockDescriptors
- Renaming of End-to-End protections could cause problems during later updates because the End-to-End protections couldn't be found anymore
- Compatibility of Application Value and Constant Reference wasn't checked
- Data-Type element information wasn't stored correctly at the root data type and vice versa
- The exported or saved component type file didn't contained all runnables
- Multiple System-Mappings (e.g. one for data mappings and another one for pnc mappings) couldn't be imported correctly.
- Loading a workspace was aborted with a NullReferenceException if the project contained multiple identical data mappings with unresolvable references
- ARXML import didn't succeed due to an endless loop if the ARXML contained array definitions with a huge array size
- Application ports couldn't be assigned anymore at the RoleBasedPortAssignments
- Mode Declaration Value range wasn't checked and the value was set to 0
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Function "Replace legacy data types" wasn't executed if LibraryBrowser had the focus
- Wrong unused item was deleted if item with the same name existed in different packages
- Physical to internal compu scales weren't displayed and were deleted when leaving the dialog
- The data transformation flag of a signal couldn't be set due to a read-only checkbox in the dialog
- Bitfields greater than 31 bits weren't handles correctly in consistency check and dialog
- Offset of End-to-End Protection profile 5 wasn't editable
- Signal group dialog accidently allows editing the signal group name and group signal set
- Create port prototype threw an "Invalid pointer" exception if signals of a signal group didn't have a base-type defined
- ARXML export wasn't possible with multi selection of Port Blueprints or Blueprint Mappings Sets
- Consistency check 40439 didn't reflect AUTOSAR constr_1295 correctly
- Crash during SWC check on runnable data accesses by value has been fixed
- Contract phase generation couldn't be used at the ECU-Project
- When using the "Propagate Alive Timeout" function a wrong value was set after loading the value from the communication extract
- Multi-select unmap of data mapping didn't work for complex data elements
- Renaming a package didn't work correctly for DCF workspaces
- Data-mapping of atomic ports lead to "Unsupported communication pattern" errors because create ECU-Delegation port didn't consider new connections
- Create Port Prototypes didn't reference newly created global constants
- Constant References could be created without a destination constant
- Invalid mode accesses are created while importing an AUTOSAR3 file with P-Ports into an AUTOSAR4 workspace
- Rte generator threw an error "[Internal Error] RTE - Could not read GenAPI data" if an argument order index of an Operation-Prototype wasn't unique
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.11 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- The official 'ServiceProvider' attribute is now supported to annotate the BSW Module origin
- The pointer datatype DATA_REFERENCE is now fully supported
- End-to-End protections without port references but with signal group references are now supported
- 'Create Port Prototypes' functionality now supports the signal group degradation use case
Usability enhancements
- Invalid generic attribute definition files are now displayed in the Action-Log during workspace loading
- Additional check has been added to ensure that the compu-methods category of an implementation data-type is either BITFIELD_TEXTTABLE or TEXTTABLE
- Additionally merged usability enhancements from service packs of previous releases:
- The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
- Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
- Menu command to reset the toolbar and docking window layout has been added
- Find results view now displays the parent element in a separate column
- Multi-select and default settings usability enhancements for End-to-End Protection configuration
- The available filter options from the import dialog are now available via command line DVImEx
- Structure graphics is now changeable even if the composition type is locked
- Multi-select editing of Communication Specification values is now supported
- A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
- Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
- Enhancements in consistency checks for NV components
- Import dialog now contains a simplified file/folder selection button
- Additional consistency check to avoid data types referencing a data type with the same name
Fixed issues
- The data-type-mapping-refs were cleared during update of the diagnostics data using the special import mode
- When creating a server runnable from a nv-component the name of the server-runnable was created with the pattern 'port-prototype'_'operation_name' which could lead into name clashes
- DaVinci DEV crashed without any error message if the direction of a port prototype was changed while a runnable data access existed
- Additionally merged issues from service packs of previous releases:
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- Modifications in the recent import file list caused a workspace modification
- ARXML import merge aborted when trying to merge an union data type.
- Import with function 'check for differences' aborted if a new element had to be created but its package already exists
- After creating a port from a signal using the 'Create Port Prototypes' function the port was not compatible to the signal if a physical constraint was specified
- Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
- Additionally merged issues from service packs of previous releases:
- AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
- AUTOSAR 4 import of a negative exponential value ignored the sign
- Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
- Creating an OnTransitionTrigger from the runnable context menu didn't work
- Not all Asian characters could be used in description fields
- Find unused object menu was sometimes disabled
- Create Port-Prototypes function didn't create record data-types for signal groups
- Developer crashed when importing an enumeration data type with physical and internal constraints
- AUTOSAR 4: Signal-Port time out value was not imported
- AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
- An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
- Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
- Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
- The name of an imported argument prototype wasn't imported correctly
- End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
- Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
- Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
- Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
- NV component couldn't be configured in the local composition view
- Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
- Blueprints couldnt be exported to DCF
- Crash fixed if context component for create port prototypes was selected as "none"
- AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
- AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
- The data type reference of a calibration element prototype wasn't set after import
- Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
- Copying a runnable broke the data model and causes undesired wait points
- Duplicating an Object copied the original UUID instead of creating a new one.
- HTML links in descriptions didn't appear in the report
- Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group
DaVinci Developer Version 3.11
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- COM-based Transformer can now be configured; supporting End-to-End Protection profiles 1+2
- Enhancements of NV Block SWC:- supporting now also Client/Server- and ModeSwitch-interfaces
- explicit modelling of different writing strategies
- multiple NvBlock to port mappings for dual-sided RAM block access
 
Usability enhancements
- Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
- Enhanced tool interaction allows to create Service-Ports directly from within DaVinci Configurator Pro
Fixed issues
- In rare cases the library tree contained obsolete items due to a missing update
- UUIDs of SwcServiceDependencies and NvBlockDescriptors were missing in the ARXML export
- Tool crashed when a locked component type was assigned to the DataTypeMappingSet in the Data-Type-Mapping-Set dialog
- If the workspace was part of a DPA project a XML parser error code 0x800C0006 was shown when opening a DCF workspace from Windows Explorer with a double click
DaVinci Developer Version 3.10 (SP5)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Additionally merged tool features from service packs of previous releases:
- Various Diff/Merge extensions to support sub-elements e.g. internal behavior
Usability enhancements
- Additionally merged usability enhancements from service packs of previous releases:
- Consistency check 40269 has be enhanced to accept a data length of 0 for Intra-ECU End-to-End Protection
- The ImportModePreset is now respected when importing the DataMapping so that the mapping of a Delegation-Port with 'keep' will not be deleted
Fixed issues
- Additionally merged issues from service packs of previous releases:
- When importing a Calibration Software Component the constant-reference in the role of an init-value wasn't set
- Contract phase generation couldn't be used at the ECU-Project
- Crash during SWC check on runnable data accesses by value has been fixed
- Inter-Runnable-Variables and Port Accesses weren't merged correctly which lead into multiple definitions
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- In some cases a double click on a .dcf file started the wrong DaVinci Developer version
- Create port from signal didn't create correct init values in all cases
- Saving a workspace aborted with "invalid argument" error if the ECU-Extract contained incorrect E2E connections
- A component type DCF file accidently contained data constr elements
- Init value constant contained duplicate record elements after merge
- GUI crashed when calling "Show in other views" on a found object
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Loading a DCF workspace crashed if the .dcf file contained an absolute file reference with more than 260 characters
- Port interfaces were are not updated correctly when overwriting a sender receiver port interface with a mode switch interface (or vice versa)
- Deleting a runnable caused an error during workspace saving if a Calibration Parameter or Per-Instance Memory exists at the software component
DaVinci Developer Version 3.10 (SP4)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Find function for objects with duplicate UUIDs has been added
Usability enhancements
- The range setting of 0..0 for CompuScales which didn't define an upper/lower limit is now supported as optional in ARXML export
- Additionally merged usability enhancements from service packs of previous releases:
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Function "Replace legacy data types" wasn't executed if LibraryBrowser had the focus
- Wrong unused item was deleted if item with the same name existed in different packages
- Physical to internal compu scales weren't displayed and were deleted when leaving the dialog
- The data transformation flag of a signal couldn't be set due to a read-only checkbox in the dialog
- Bitfields greater than 31 bits weren't handles correctly in consistency check and dialog
- Offset of End-to-End Protection profile 5 wasn't editable
- Signal group dialog accidently allows editing the signal group name and group signal set
- Create port prototype threw an "Invalid pointer" exception if signals of a signal group didn't have a base-type defined
- ARXML export wasn't possible with multi selection of Port Blueprints or Blueprint Mappings Sets
- Consistency check 40439 didn't reflect AUTOSAR constr_1295 correctly
- Crash during SWC check on runnable data accesses by value has been fixed
- Contract phase generation couldn't be used at the ECU-Project
- When using the "Propagate Alive Timeout" function a wrong value was set after loading the value from the communication extract
- Additionally merged issues from service packs of previous releases:
- Multi-select unmap of data mapping didn't work for complex data elements
- Renaming a package didn't work correctly for DCF workspaces
- Data-mapping of atomic ports lead to "Unsupported communication pattern" errors because create ECU-Delegation port didn't consider new connections
- Create Port Prototypes didn't reference newly created global constants
- Constant References could be created without a destination constant
- Invalid mode accesses are created while importing an AUTOSAR3 file with P-Ports into an AUTOSAR4 workspace
- Rte generator threw an error "[Internal Error] RTE - Could not read GenAPI data" if an argument order index of an Operation-Prototype wasn't unique
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.10 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- End-to-End protections without port references but with signal group references are now supported
- 'Create Port Prototypes' functionality now supports the signal group degradation use case
Usability enhancements
- The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
- Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
- Menu command to reset the toolbar and docking window layout has been added
- Find results view now displays the parent element in a separate column
- Multi-select and default settings usability enhancements for End-to-End Protection configuration
- The available filter options from the import dialog are now available via command line DVImEx
- Structure graphics is now changeable even if the composition type is locked
- Multi-select editing of Communication Specification values is now supported
- A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
- Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
- Enhancements in consistency checks for NV components
- Import dialog now contains a simplified file/folder selection button
- Additional consistency check to avoid data types referencing a data type with the same name
Fixed issues
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- Modifications in the recent import file list caused a workspace modification
- ARXML import merge aborted when trying to merge an union data type.
- Import with function 'check for differences' aborted if a new element had to be created but its package already exists
- After creating a port from a signal using the 'Create Port Prototypes' function the port was not compatible to the signal if a physical constraint was specified
- Additionally merged issues from service packs of previous releases:
- Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
- Additionally merged issues from service packs of previous releases:
- AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
- AUTOSAR 4 import of a negative exponential value ignored the sign
- Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
- Creating an OnTransitionTrigger from the runnable context menu didn't work
- Not all Asian characters could be used in description fields
- Find unused object menu was sometimes disabled
- Create Port-Prototypes function didn't create record data-types for signal groups
- Developer crashed when importing an enumeration data type with physical and internal constraints
- AUTOSAR 4: Signal-Port time out value was not imported
- AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
- An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
- Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
- Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
- The name of an imported argument prototype wasn't imported correctly
- End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
- Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
- Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
- Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
- NV component couldn't be configured in the local composition view
- Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
- Blueprints couldnt be exported to DCF
- Crash fixed if context component for create port prototypes was selected as "none"
- AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
- AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
- The data type reference of a calibration element prototype wasn't set after import
- Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
- Copying a runnable broke the data model and causes undesired wait points
- Duplicating an Object copied the original UUID instead of creating a new one.
- HTML links in descriptions didn't appear in the report
- Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group
DaVinci Developer Version 3.10 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Various roundups and extensions have been implemented for the Diff/Merge functionality, especially support for NV-Data-Interfaces and Packages
- Function "Create Port Prototypes" can now be used on signals that don't have a base type
Usability enhancements
- ARXML import dialog can now load an external .txt file that contains a list of the file name references to be imported. Paths can be absolute, relative (to the .txt itself) and just the filename itself (same directory).
- Saving a DCF workspace can now remove files for deleted objects. This option can be activated in the workspace settings.
Fixed issues
- If falsely an invalid Invoke Operations Port-Access was defined on a non-Client port, the DCF workspace couldn't be loaded anymore
- A project wasn't updated correctly if the elements were part of a package named "Autosar_Platform".
- Exporting a Mode Declaration Group contained the category. This category is now corrected to the ALPHABETICAL_ORDER or EXPLICIT_ORDER.
- In some cases the diff/merge crashed when importing communication data with "check for differences" option.
- Importing an new ECU SW-Composition delegation port in a previous workspace with "check for differences" option enabled, the data mapping of this port wasn't created.
- Error 40391 "Invalid integer for criterion" was reported if the project contained more than 4 variants
- For some object types the package icon was missing in the Library Browser's type view
- Item is read-only error occurs when opening a SWC composition that contained a read-only atomic SWCs with an outdated interface graphic.
- The references to a Mapping Set from a NvBlockComponent were not persistent
- Automatic data type mapping falsely created a fix-size implementation array for a dynamic-size application array
- Function "Create Server Runnables" created duplicate runnables and allowed invalid prefix / postfix strings
DaVinci Developer Version 3.10 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Vector FlexNet Pool License model is now supported
- Support for signals which are transmitted over container PDUs has been added
Fixed issues
- Exception was raised when adding a file to the ARXML import list if a J1939 cluster contained a NODE-NAME and the ECU-INSTANCE attribute
- DVImEx command line tool falsely showed the message "Referenced DPA file from the DCF workspace differs to the load DPA file" if a relative path was given
- TP Signals weren't displayed with the correct frame in the Data-Mapping view for the 1:N use case
- Some smaller GUI roundups and fixes have been made when using union data types
DaVinci Developer Version 3.10
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Mapping of Data-Prototypes in different Port-Interfaces is now supported
- Text table mapping for Bit fields is now available
- Background event trigger can now be defined at the runnable
- End-to-End protection profiles 5 and 6 are now supported
- UTF-16 base type encoding can now be specified
- UNION data types are now supported
Usability enhancements
- More detailed log messages during ARXML import if generic attributes reference obsolete objects
- Additional checks to detect more NvM Service Need inconsistencies
- AUTOSAR Platform types are now defined in a separate ARXML file and automatically used for new projects
- The path to the .dpa project file is now stored in the .dcf file to allow manual adaptation
Fixed issues
- ARXML import throws an error if the same Client/Server interface was defined in multiple files which were imported in the same step
- Consistency check reports incompatible data types if the Type-Emitter where different
- Communication information was accidently removed when importing a SYSTEM with software design but without communication
DaVinci Developer Version 3.9 (SP4)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Usability enhancements
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- Multi-select unmap of data mapping didn't work for complex data elements
- Renaming a package didn't work correctly for DCF workspaces
- Data-mapping of atomic ports lead to "Unsupported communication pattern" errors because create ECU-Delegation port didn't consider new connections
- Create Port Prototypes didn't reference newly created global constants
- Constant References could be created without a destination constant
- Invalid mode accesses are created while importing an AUTOSAR3 file with P-Ports into an AUTOSAR4 workspace
- Additionally merged issues from service packs of previous releases:
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.9 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Fixed issues
- Standard Nvm interfaces were missing on creating a new AR 4.1.3 workspace
- Migration of a DCF workspace to a different AUTOSAR schema version wasn't possible because the SaveAs menu entry was disabled
- Record Constant dialog couldn't be opened for the port prototype if a Com-Spec wasn't defined at the data element of the port
- Create Port Prototypes function created an invalid init value for complex data types
- ARXML import threw a fatal error if the same client-server interface was specified in different files and the files were imported at the same time
- The automatic Application to Implementation Data-Type Mapping falsely created a fix-size Impl-array for a dynamic-size Appl-array and reported this as invalid mapping
- Not all Asian characters could be used in description fields
DaVinci Developer Version 3.9 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Compatibility checks for Bit fields have been improved
Usability enhancements
- Output of check message 40224: "Unused data element prototype" can now be omitted by the option "Report unused Data Elements" in the workspace setting dialog
- Command line tool DVImEx now supports the "SubstituteMissingObjects" option
- For iterative import/export workflow purposes an additional import option "Keep existing UUIDs" is now available
- Additional function "Adopt structure..." to align the value definition structure to the structure of the actual data type
- In selection dialogs the init values are now filtered according to the data type
Fixed issues
- Referenced mode declaration groups were missing in DCF export when data type mapping sets where used
- In rare cases the relative DPA project file path couldn't be found if the current directory had been changed via the open file dialog
- End-to-End protection consistency check didn't worked within compositions
- Port access settings of runnables were invalid after they were copied in the runnable list
- Frame assignment was not visible for Signal-PDUs which were connected to a NPDU via the TP-Connection
- Multiple recursive usage of constant references leaded to an exception
- Data mapping for Signal-Groups didn't worked if Sub-Elements were incompatible
- Cancel button for "InitValue" of Record- and Array data types had no effect
DaVinci Developer Version 3.9 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- AUTOSAR schema 4.2.1 is now supported
- Memory Section assignment is now available for NvBlockDescriptor:RAMBlock
- PR-Ports can now be used for Mode-Ports and NvData-Ports
- Bit field data types are now supported by using the BITFIELD_TEXTTABLE in the compu-method
Usability enhancements
- Workspace interaction with DaVinci Configurator has been enhanced by using a lock file mechanism during workspace save
- Creation of a Data-Mapping for a variant signal now evaluates the variant information to set the same variant condition
Fixed issues
- Data element properties couldn't be opened from within the Data Mapping signal view
- Interfaces View in software component editor was falsely disabled for NvComponents
- Most recently used workspace list showed the location of the temporary workspace after a project update using DaVinci Configurator
- Frame was not imported if a frame triggering specifies RX-IDENTIFIER-RANGE instead of IDENTIFIER
- DCF workspace couldn't be loaded if the port direction was changed without performing a consistency check which will correct the port connector
- Error message 'Current special import can only import System Template files' was thrown when using special import feature
- Tool tip didn't work when hovering over a array constant with many values
- LIN-PDUs without frame triggerings couldn't be imported
- Consistency checks for NV-Component init values have been corrected
- DCF workspace contained elements with the same UUID if the component type was duplicated by the copy function in the Library-View
- It was falsely possible to update the project in DaVinci Configurator when the workspace was opened in DaVinci Developer
- PR-Port generation didn't work in case of a complex data type
DaVinci Developer Version 3.9
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Post-Build selectable use-case is now supported by using AUTOSAR Variant Handling for data-mapping with variation points at the communication
- General support of PDUs without frames has been implemented for all cluster types
- Communication data has been restructured so that DaVinci Developer can directly work on DaVinci Configurator's communication files
- COM signals with shared ISignalToIPDUMapping are now supported
- uint64 and sint64 are now supported as platform types
- Server argument implementation policy attribute is now supported in the operation prototype dialog
- Port access mode 'ReceivePointByValue' is now supported
- End-to-End protection now supports profile 4 for Client/Server inter-ECU communication
- Optional definition of service need parameters
Usability enhancements
- Additional 'Check Workspace' button is now available in the toolbar
- Project update has been simplified to update the DaVinci Developer workspace without user interaction
Fixed issues
- 'Complete Ports' functionality produced wrong opposite ports if a context component type was used
- 'Save As...' functionality has been disabled for projects with DaVinci Configurator Pro because it corrupted the external file references
- HTML links in the description field were not correctly displayed in the report
- The Diagnostics Event Need value 'ConsiderPTO Status' was not correctly set by ARXML import
- Project update with DaVinci Configurator Pro command line tool ended with error -1060110332 (0xC0D00004)
- Port Defined Argument Value could falsely be defined on non-server ports
- Consistency check of the Rte generator falsely reports consistency errors when started within DaVinci Developer
- Consistency check of service needs caused memory leaks
DaVinci Developer Version 3.8 (SP4)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- End-to-End protections without port references but with signal group references are now supported
- The 'Create PortPrototype from Signal' functionality now supports the signal group degradation use case
Usability enhancements
- The import option 'Substitute missing objects' is now active by default for new workspaces. The import defaults can be set via the workspace settings dialog.
- Additionally merged enhancements from service packs of previous releases:
- Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
- Menu command to reset the toolbar and docking window layout has been added
- Find results view now displays the parent element in a separate column
- Multi-select and default settings usability enhancements for End-to-End Protection configuration
- The available filter options from the import dialog are now available via command line DVImEx
- Structure graphics is now changeable even if the composition type is locked
- Multi-select editing of Communication Specification values is now supported
- A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
- Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
- Enhancements in consistency checks for NV components
- Import dialog now contains a simplified file/folder selection button
- Additional consistency check to avoid data types referencing a data type with the same name
Fixed issues
- Data mapping of a complex element to a transformed signal causes inconsistencies in the data mapping view
- Additionally merged issues from service packs of previous releases:
- AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
- AUTOSAR 4 import of a negative exponential value ignored the sign
- Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
- Creating an OnTransitionTrigger from the runnable context menu didn't work
- Not all Asian characters could be used in description fields
- Find unused object menu was sometimes disabled
- Create Port-Prototypes function didn't create record data-types for signal groups
- Developer crashed when importing an enumeration data type with physical and internal constraints
- AUTOSAR 4: Signal-Port time out value was not imported
- AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
- An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
- Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
- Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
- The name of an imported argument prototype wasn't imported correctly
- End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
- Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
- Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
- Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
- NV component couldn't be configured in the local composition view
- Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
- Blueprints couldnt be exported to DCF
- Crash fixed if context component for create port prototypes was selected as "none"
- AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
- AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
- The data type reference of a calibration element prototype wasn't set after import
- Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
- Copying a runnable broke the data model and causes undesired wait points
- Duplicating an Object copied the original UUID instead of creating a new one.
- HTML links in descriptions didn't appear in the report
- Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group
DaVinci Developer Version 3.8 (SP3)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Usability enhancements
- Missing compu-method category in ARXML file is now added by the import with a reasonable value
- Additional option in SaveAs... to migrate the version of an existing DCF workspace in-place without changing the project structure
- External service components change detection doesn't show the import dialog any more
- Check for multiple signal group mappings is now enhanced enhancement for PR-Ports
- Multiple selection of objects in several packages is now supported in the Library-View package tab
Fixed issues
- The data reception trigger couldn't be created for a NV-DataElement
- DCF workspace couldn't be loaded if data accesses exist without data element prototype
- Setting to deactivate End-to-End protection consistency checks was loaded always enabled
- Newly created data type/constant was added to the default package instead of the selected package
- Auto connect created redundant connections for PR-ports if they were already connected
- Obsolete data mappings were displayed in the signal mode of the data mapping view when the data transformation was enabled
DaVinci Developer Version 3.8 (SP2)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Usability enhancements
- An additional "Check Workspace" button is now available to check the full workspace independent from the selected element
- The layout and content of NV Block Component Types has been adapted to match the NvM Block Needs page of regular SWC types
Fixed issues
- AUTOSAR 3 workspaces could still be created which is no longer supported in this release
- References to compu method and data constraints were missing if Signals are defined prior to the referenced elements in the ARXML file
- An empty NUMERIC-VALUE-SPECIFICATION was exported if a communication specification hadn't defined any init value
- In rare cases DCF workspace couldn't be saved due to duplicate short names
- AUTOSAR 3 cross-import didn't understand hex string values like "A0:A1:A2"
- The Rte generation added ComGroupSignals to the ECU-C configuration although they are not related to the ComSignalGroup
- Memory leaks occurred during consistency check of service needs
- Wrong focus selection handling in service needs edit files has been corrected
DaVinci Developer Version 3.8 (SP1)
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Export to AUTOSAR schema version 4.1.1 is now supported
- Application-Ports are now supported at Service Components
Fixed issues
- Keyboard-navigation through editors(Ctrl+HOME/Ctrl+END) didn't work anymore
- Invalid NvM ServiceNeeds configuration wasn't exported to ARXML
- Import of component type was canceled if a port defined argument value existed and its value didn't define a short label.
- ARXML import crashed when importing an inconsistent array data type
- AUTOSAR 3 cross-import didn't import the system signals into the specified package
- "Parameter is incorrect" exception was threw during copying a data element
- Data exchange analysis showed no communication if an incompatible connector existed in the software design
- "Adapt Connected Port Prototypes" functionality failed when using PR-Ports
- Port assignments at the service needs got lost when opening a DaVinci DEV 3.6 workspace
- ARXML import update use-case didn't work with init-triggers in 4.1.2 format
- PR-Ports aren't shown as compatible in the Connector Dialog
DaVinci Developer Version 3.8
NOTE
This release is only relevant for AUTOSAR 4.
AUTOSAR 3 is supported by DaVinci Developer Version 3.7 or previous releases.
Tool features
- Combined provide-require-ports (PRPortPrototype) can be defined in the software design
- Explicit modelling of E_OK as application error is now possible
- Service Needs have been extended for NvM Top-Down service configuration
- OBD Ratio Service Need has been added
- Introducing Sender/Receiver Serialization via Transformer concept (AR4.2.1 preview-feature)- Data transformation currently only supported for SOME/IP serialization
- Inter-Ecu Client/Server Communication is available for signals using data transformation
- Specific End-to-End protection profiles for data transformation have been added
- End-to-End protection is now supporting also primitive data elements
 
Usability enhancements
- Init-Runnables are described with the standardized AUTOSAR InitEvent
- TypeReferences now support Data-Constraints
- Data Exchange Analysis now displays the effective Init-Value
DaVinci Developer Version 3.7 (SP9)
Usability enhancements
- Find unused data types was very slow on a large amount of objects
- Save workspace was very slow if many data types were deleted
Fixed issues
- ARXML import removed a Runnable Data Access if a referencing Variable Data Prototype was renamed in the imported ARXML file
- Description for nested data types was incorrectly stored when saving a workspace.
- ARXML import crashed if an array data type referenced an undefined base type
- An invalid Port Terminator was not removed by the workspace check
- If a Port Interface had several Data Elements, the multi-edit function for Com-Spec settings on a SWC was not working
- DCF workspace with a single tx ack only runnable access couldn't be opened anymore
- DCF workspace with an unnamed runnable mode switch point couldn't be opened anymore
DaVinci Developer Version 3.7 (SP8)
Tool features
- AUTOSAR 3 ECU-C synchronization now supports application refs of OS resources if the OS applications use exclusive areas as interruption mechanism
- Various Diff/Merge extensions to support sub-elements e.g. internal behavior
Usability enhancements
- Consistency check 40269 has be enhanced to accept a data length of 0 for Intra-ECU End-to-End Protection
- The ImportModePreset is now respected when importing the DataMapping so that the mapping of a Delegation-Port with 'keep' will not be deleted
Fixed issues
- When importing a Calibration Software Component the constant-reference in the role of an init-value wasn't set
- Contract phase generation couldn't be used at the ECU-Project
- Crash during SWC check on runnable data accesses by value has been fixed
- Inter-Runnable-Variables and Port Accesses weren't merged correctly which lead into multiple definitions
- Error 'XML parser error code 0x800C0006 in file .' was displayed when opening a DCF workspace with relative paths to a DPA file
- In some cases a double click on a .dcf file started the wrong DaVinci Developer version
- Create port from signal didn't create correct init values in all cases
- Saving a workspace aborted with "invalid argument" error if the ECU-Extract contained incorrect E2E connections
- A component type DCF file accidently contained data constr elements
- Init value constant contained duplicate record elements after merge
- GUI crashed when calling "Show in other views" on a found object
- Search function didn't find all objects of type "Blueprint" or "Blueprint Mapping Set"
- Loading a DCF workspace crashed if the .dcf file contained an absolute file reference with more than 260 characters
- Port interfaces were are not updated correctly when overwriting a sender receiver port interface with a mode switch interface (or vice versa)
- Deleting a runnable caused an error during workspace saving if a Calibration Parameter or Per-Instance Memory exists at the software component
DaVinci Developer Version 3.7 (SP7)
Usability enhancements
- DVImEx command line tool now prints timestamps in the log output
- Using the 'OpenWith' functionality in Windows Explorer now checks if the correct DaVinci Developer version is used for a referenced .dpa project
Fixed issues
- AUTOSAR 3 enumerators were not persistent if entered or changed via the GUI
- AUTOSAR 3 import created superfluous delegation ports for extended connections/mappings
- AUTOSAR 3 export created the same UUID for an init runnable trigger and the runnable itself
- AUTOSAR 3 export converted an application layer CDD to a service layer CDD
- AUTOSAR 3 export created identical names for a RecordElementConstant literal name and the RecordElement name
- Rte generator threw an error "[Internal Error] RTE - Could not read GenAPI data" if an argument order index of an Operation-Prototype wasn't unique
- Data-Mapping wasn't correct if a signal was received as single signal and was contained but not received as part of a group
- Update in the package view was missing when short-names have been changed
- Signals couldn't be mapped on primitive data elements if they were part of a signal group
- EnableUpdate flag handling in the Com-Spec dialog was wrong if UsesE2EProtection flag was cleared
- The attributes of a NvMBlockServiceNeed couldn't be edited via a PIM
- Create Port from Signal didn't create init values correctly
- Object-Usage of port prototype blueprint didn't show the referencing objects
- Object-Usage dialog didn't display the correct icons in all cases
- The menu commands for generation of "Contract Phase Headers" and "Component Implementation Templates" were mixed up
- Obsolete RoleBasedPortAssignments were not deleted
- Port terminator annotation wasn't always persistent
DaVinci Developer Version 3.7 (SP6)
Tool features
- End-to-End protections without port references but with signal group references are now supported
- 'Create PortPrototypes' functionality now supports the signal group degradation use case
Usability enhancements
- Enhanced contract phase template generation dialog; automatically offers the Rte generator from the referenced SIP if available
- Menu command to reset the toolbar and docking window layout has been added
- Find results view now displays the parent element in a separate column
Fixed issues
- AUTOSAR 4 import of Group-Signals didn't update all signal references correctly which resulted in an illegal file split error in DaVinci Configurator Pro
- AUTOSAR 4 import of a negative exponential value ignored the sign
- Export option 'Create UUIDs' wrote identical UUIDs for all signal- and frame ports
- Creating an OnTransitionTrigger from the runnable context menu didn't work
DaVinci Developer Version 3.7 (SP5)
Usability enhancements
- Multi-select and default settings usability enhancements for End-to-End Protection configuration
- The available filter options from the Import dialog are now available via command line DVImEx
- Structure graphics is now changeable even if the composition type is locked
- Multi-select editing of Communication Specification values is now supported
- A dedicated 'order index' column has been added for lists that have a relevant order in the ARXML schema
Fixed issues
- Not all Asian characters could be used in description fields
- Find unused object menu was sometimes disabled
- Create Port-Prototypes function didn't create record data-types for signal groups
- Developer crashed when importing an enumeration data type with physical and internal constraints
- AUTOSAR 4: Signal-Port time out value was not imported
- AUTOSAR 4: Not all Parameter-Accesses were exported for modelled calibration elements
- An internal exception occurred on ARXML import if an existing component type had a different internal behavior name and a runnable with the same name
- Importing an AUTOSAR 3 array without type-reference into an AUTOSAR 4 workspace created an invalid the data-type
- Duplicate UUIDs occurred when creating a Multiple-ECU project from ECU Extracts containing UUIDs
- The name of an imported argument prototype wasn't imported correctly
- End-to-End protection data IDs were mixed up when opening an old workspace saved with DaVinci Developer 3.2
- Unlocking a composition didn't allow moving its ports/component prototypes until the ECU-Project editor was reopened
- Create port from signal didn't worked for multiple signals if the data mapping wasn't created in the same step
DaVinci Developer Version 3.7 (SP4)
Tool features
- Export of ARXML files with AUTOSAR schema 4.1.1 is now supported
- Support of signals sent on several frames on several channels of a cluster has been added
- Text-ValueSpecification can now be used as init value for an Enum Data-Type
- AUTOSAR 3: Service Mapping for S/R Ports supports now n:1 connections
Usability enhancements
- Automatic data-mapping can now be disabled while creating port-prototypes
- Select-All in Library view no works as a 'deep select' on all subjacent items
- 'Flip Direction' command is now available at port prototypes in the Component Editor
- After Copy&Paste of port prototypes to the port list, the new ports are now selected automatically
Fixed issues
- ECU-C synchronization added unnecessary COM-Callbacks if the same OS application was used by multiple tasks
- Illegal file split was created during project update if signals have been moved into a signal group of a different package
- End-to-End Protection profiles _XOR and _XOR+2 didn't allow a DataID of 0
- DVImEx command line tool didn't export all referenced elements
- Record element literals were not unique after adapting record constants to a modified structure
- The DCF save of a software component was incomplete if obsolete Port-Accesses existed
- Crash during ARXML import fixed if AUTOSAR 3 objects are imported in a new, empty DEV workspace with the ''Substitute missing Objects' flag enabled.
- Import/export of the SYSTEM element didn't preserve the original system name
- Unconnected data mappings of TX/RX signal with two different data elements were not persistent in AUTOSAR 3 DCF workspaces
- Signals with an invalid-value and an init-value lead to a duplicate short-name in AUTOSAR 4
- Signals were missing after AUTOSAR 4 import if the ECU-Extract contained one or more Ethernet clusters.
- Calibration-Support flag of NvBlockSwComponentTypes and ServiceComponentTypes was not written to the ECU-Configuration file
- DCF utility tool didn't support DCF workspace with AUTOSAR 4.1.3 schema
- After using the function 'Adapt connected Ports' an error message 'Typeconflict (code 0x80020005)' was produced when opening the port properties.
DaVinci Developer Version 3.7 (SP3)
Tool features
- Import of ARXML files with AUTOSAR schema 4.1.3 is now supported
Usability enhancements
- AUTOSAR 3 import now reports an error if multiple component types reference the same internal behavior
Fixed issues
- Create Port Prototype functionality sets the wrong package for existing data types
- AUTOSAR 3 IMC import/update for a Multiple-Config project produced a 'fake' error message that renamed objects exists but no objects were actually renamed
- AUTOSAR 4 import caused a stack overflow exception when importing an array without sub-elements
- Init-Trigger handling was corrected to support legacy convention with a '0' cycle time
DaVinci Developer Version 3.7 (SP2)
Usability enhancements
- Performance enhancement when loading communication data of a DCF workspace
- Separate layout toolbar for direct modification of graphic port layout
Fixed issues
- 'Substitute missing objects' functionality didn't work anymore with AUTOSAR 4 import files
- Error message 'Invalid pointer code 0x80004003' was thrown when using "Create Port Prototypes" dialog
- Crash fixed when creating a reference from PIM to NvMBlockNeed or the other way around
- DaVinci Difference Analyzer command line didn't accept FlexNet license on 64bit Windows
- Port defined argument values at Application Components couldn't be stored correctly in DCF format and AUTOSAR 3 export
- AUTOSAR 3 import of enumerations didn't work if an enumeration value had the same name but a different position
DaVinci Developer Version 3.7 (SP1)
Fixed issues
- The 'Last Import' timestamp in the ECU-Project's properties dialog was wrong if service components were loaded on opening the workspace
- Unmodified software components where falsely updated on DCF saving if package information was imported which was actually the same
- Import an existing software component with 'Keep Realization' option was wrong if existing ports with runnable accesses were deleted
- When importing a communication specification of a composition port with an init value of type constant reference the reference was not set
- When changing the kind of communication from queued to unqueued and vice versa, the corresponding communication specifications of ports were not updated on DCF saving
- The 'Find unused Base Types' functionality didn't consider new references of mapped signals
- Some ports were missing after import of an imc file for a multiple configuration project if a port with the same name but different port interface already exists
- After import of the mecu file for a multiple ECU project the data mapping was incomplete if a signal group and their group-signals were mapped in different identities
DaVinci Developer Version 3.7
Tool features
- General support for AUTOSAR schema 4.1.1 and 4.1.2
- AUTOSAR 4 Port-Groups for definition of Virtual Functions Clusters
- J1939-CLUSTER is now supported with AUTOSAR schema 4.1.1 and 4.1.2
- Enhanced PDU design for Ethernet/IP-Cluster to allow PDUs without frame mapping
- Create Port Prototype from data mapping based on a given signal as available for AUTOSAR 3 can now be used for AUTOSAR 4 too
- Adapt Data Type for Data Element based on a given signal as available for AUTOSAR 3 can now be used for AUTOSAR 4 too
- Various Service Needs extensions and GUI reworks with support of Role-Based port assignment
- Improved definition of invalid value of application data types
Usability enhancements
- Various improvements in roundtrip workflow between DaVinci Developer and DaVinci Configurator Pro
- Some additional data-mapping and compatibility checks for AUTOSAR 4 data types
- End-To-End Protections now have a default package like other design objects
Fixed issues
- The 'check for differences' functionality created a new ECU-Project if the project name differed from the System Extract name
- The 'check for differences' functionality is now disabled in project update use-case since it corrupted the workspace data
- The data-type invalid value couldn't handle float values
- Circular constant references caused a crash when opening such a constant in an editor
- Incompatible init value was reported even if the data-types are compatible
- DCF Utility couldn't handle AUTOSAR 4 DCF workspaces correctly and falsely reported corrupted ARXML files
- Generic attributes of nested data types where incorrectly stored in AUTOSAR 4 DCF workspaces
- DCF workspace couldn't be loaded anymore if a component type or ECU-Project contains an attached file
DaVinci Developer Version 3.6 (SP4)
Usability enhancements
- Import options 'substitute missing objects' and 'check for differences' are now supported in the same import step
- Enhancements in consistency checks for NV components
- Import dialog now contains a simplified file/folder selection button
- Additional consistency check to avoid data types referencing a data type with the same name
Fixed issues
- Crash was fixed when leaving the NV Block descriptor page of a NV Component editor without having a Block Descriptor defined
- NV component couldn't be configured in the local composition view
- Inter-Runnable-Variable data type wasn't exported to DCF if their component type contained an Inter-Runnable-Variable with a unique data type which wasn't used in any other case
- Blueprints couldnt be exported to DCF
- Crash fixed if context component for create port prototypes was selected as "none"
- AUTOSAR4: init value of NV block description (ram or rom) couldn't be unset
- AUTOSAR4: Substitute missing objects showed irrelevant unresolved references
- The data type reference of a calibration element prototype wasn't set after import
- Import of a DCF package accidently sets the workspace option "Load Service Components when opening the workspace" to a wrong value
- Copying a runnable broke the data model and causes undesired wait points
- Duplicating an Object copied the original UUID instead of creating a new one.
- HTML links in descriptions didn't appear in the report
- Data mapping view didn't display the correct direction of signals which were sent/received as single signal and as part of a signal-group
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.6 (SP3)
Usability enhancements
- Category items in the Library Browser now have a 'Select All' functionality
- Separate layout toolbar for direct modification of graphic port layout
- Data Type Mapping Set dialog now supports multiple selection and modification through context menu
Fixed issues
- Unmodified objects will no longer update files in the DCF workspace
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.6 (SP2)
Usability enhancements
- Description field in property dialogs or property view now supports hyperlinks with link execution
Fixed issues
- Local .CPG FlexNet license couldn't be checked out if multiple DaVinci Developer licenses are activated in parallel
- ECU-C synchronization of OsSpinlock wrote invalid OsApplication-Refs
- Exporting a nested composite data mapping failed and the ECU-Extract didn't contain the data mapping of the nested array
- An ARXML export became invalid on exporting a symbol-value of component type which didn't fulfill the C-Identifiable pattern.
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.6 (SP1)
Usability enhancements
- Enhanced display of information in the 'About Dialog' if no valid license can be found.
- Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
Fixed issues
- Copy/Paste didn't work if the workspace path contains the "," character
- Duplicate Software Component appeared in LibraryBrowser when re-opened the workspace after creating a workspace snapshot
- The 'find unused' function for TypeMappingSets showed also elements in use
- Workspace elements were editable even if the corresponding DCF arxml file was read-only
- An exception occurred when importing an incomplete AUTOSAR 4 assembly connection
- The size-property or record structure of nested array constants were not updated during import into a workspace already containing this constant
- Error 'No such interface supported' with code 0x80004002 was shown twice when importing a Service-SWC by the file observation function
- DataMapping contained a network signal without a name, message, and network, if a signal was part of at least two signal groups and each of them was received or transmitted on a frame
- Implementation data types couldn't be deleted from within the Package View
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.6
Tool features
- Support for Port-Prototype blueprints in the software design
- Multi-core design is now supported by assigning a core to an OS-Application in AUTOSAR 3
- N:1 communication is now supported in AUTOSAR 4
- TP transmitted signals are now available for Data-Mapping in AUTOSAR 4
- Support of NvData-Interface and NvBlock-Component-Types in AUTOSAR 4
- System-Signals with 'dynamicLength' are now supported to address the specific use-cases for J1939 and IP
- The AUTOSAR UUID attribute is now stored for all Objects for a better roundtrip support, new Objects can also be exported with a UUID
- ARXML import of IP cluster descriptions also from AUTOSAR 4.1.1 format
- The Vector AUTOSAR Explorer is now delivered as part of the DaVinci DEV setup
Usability enhancements
- Enhanced interaction between DaVinci DEV and DaVinci CFG to detect renamed objects and refactured references accordingly
- Support of externally defined service component files which are loaded automatically as read-only elements into DaVinci DEV
- Some enhancements in aligning graphic elements and taken over attributes when copying graphic elements
Fixed issues
- AUTOSAR 4 import falsely reported duplicate item names although the file contained unique names
- AUTOSAR 4 import didn't overwrite the array size of an existing constant
- AUTOSAR 4 consistency check falsely reported an incompatible End-to-End Protection although it was valid
- Exporting a DCF workspace using DVImEx.exe threw an unknown error if the -s command line switch wasn't specified
- Property view displayed wrong item after selecting a software component prototype
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.5 (SP4)
Usability enhancements
- For graphic operations a UNDO functionality is now available
- Definition of constants has been enhanced by supporting multi-selection and in-place editing
- The HTML report now displays 'Queue Length: - ' if a data element is unqueued.
Fixed issues
- GUI falsely allowed usage of multiple underscores for the record element name of record constants
- GUI didn't allow leading underscore for the Symbol Values of Implementation Datatypes
- AUTOSAR 3 import in 'Communication only' mode didn't set the correct package information and doesn't update dependent elements
- Diff&Merge aborted with an unrelated error if the ARXML export wasn't possible
- PDUs without package couldn't be merged during AUTOSAR 3 import if the workspace already contains the PDUs without packages
- Error during DCF saving concerning consistency ID 40116 if a trigger name clash exists
- Data mapping wasn't recognized in DaVinci Configurator Pro if DaVinci Developer setting 'use default packages' was enabled
- During ARXML import the merge of existing Port-API Options was wrong if multiple port prototypes on different component types had the same name
- Data mapping view showed superfluous group signal rows which cannot be unmapped if a signal group was mapped to multiple frames and the received group signal sets were different
- ECU-C synchronization configured invalid Com callbacks if system signal was received by multiple frames and additionally as part of a system signal group
- ECU-C synchronization showed a different ComSignal name postfix if the corresponding PDUs are configured as SplitTxRxPDUs and Tx-OverlayingPDUs
- ECU-C synchronization reported invalid system signal references
- Invalid ComSignal/ISignalToIPDUMapping references were falsely reported if the corresponding ISignalTriggering didn't reference a signal port
- Component Prototype properties dialog couldn't be opened from within the component type selection dialog
- Packages could be deleted without error message even if they are in use
- Copying multiple elements in a list based view didn't work correctly and showed an error message
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.5 (SP3)
Usability enhancements
- Enhanced display of information in the 'About Dialog' if no valid license can be found.
- Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
- New technical reference for AUTOSAR 4 Data Type design
Fixed issues
- In rare cases the FlexNet license couldn't be checked out from a license server
- Check for corrupted files in DCFUtility failed when using AUTOSAR 4 workspaces
- DCFUtility showed "incompatible file version 0x6c00" error message when opening the ECU-Project binary file
- Error occurred when importing an ECU SW-Composition port with a Com-Spec without init value
- SUPPORTS-ASYNCHRONOUS-MODE-SWITCH = true leaded to missing port accesses
- The generated Rte code contained wrong ComSignal handles and/or ComSignal handles were missing.
- Loading a AUTOSAR 3 DCF workspace didn't finish in a reasonable time if End-to-End protections with deep SWC hierarchies existed
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.5 (SP2)
Tool features
- New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU
Usability enhancements
- Some AUTOSAR 4 specific basic data type checks have been implemented to ensure a valid base type, native declaration und unique naming
- Data type map consistency check message with ID 30050 has been improved by showing the concrete data type which has to be fixed
- The "Find Unsed Data Types" functionality has been improved to support all AUTOSAR 4 data type definitions
- In multiple configuration projects, delegation ports with the same name but different data types are now automatically postfixed with the identity name
Fixed issues
- After a new Project Assistant project has been created the corresponding workspace wasn't opened directly
- AUTOSAR 4 import of connections didn't work for empty component types
- Defined End-to-End connections to unconnected composition ports were lost during saving/loading a DCF workspace
- Renaming of objects like Mode Declaration Groups didn't trigger all affected files to be updated in a DCF workspace
- An existing Compu Method Reference couldn't be removed in the dialog by selecting the "none" entry
- Init values at Inter-Runnable variables weren't checked correctly for data type compatibility
- Timeout values with different units were reported as different although they were equal
- Complex Device Driver were imported as a service component type if no service- or application-ports were defined
- AUTOSAR 4 data constraints were not imported correctly if a compu-method specifies a compu-default-value
- Some memory leaks during AUTOASAR 4 import have been solved, which caused a crash during load of the DCF workspace
- Duplicated elements were imported if an element was defined in several files and contained sub-elements without a SHORT-NAME.
- The NvMBlock length and RomBlock address was not adapted during ECU-C synchronization if the NvBlockDescriptor's NvBlockNeed length was greater than 0
- Top-level connections derived from the data mapping were missing because the root composition in the ECU-Extract didn't contain connections
- Data mapping of an array DataElement to a signal wasn't supported for AUTOSAR 4 application data types
- Port prototypes, component prototypes and connections weren't deleted from the EcuSwComposition if the root composition type and/or package was renamed during updating the ECU-Extract
- After an AUTOSAR 4 communication update obsolete signal groups were still mapped on a frame
- Some communication elements were missing after opening a DCF workspace that contained PDU groups referencing other PDU groups
- Internal exception thrown during AUTOSAR 4 import if the project contained a PDU with the same name as in the imported file, except for character case.
- Message name in the data mapping view was missing if a signal was mapped on a PDU/Frame which contained signals mapped to several PDUs/Frames
- Compilation of the generated Rte code failed because of missing Rte functions in multiple configuration projects using extracts of a Multiple-ECU project
- Data IDs of different End-To-End connections were appended during update of a Multiple-ECU project
- The Array constant definition was restricted to 512 elements in the GUI
- The Rte generation showed an internal error about a missing COM signal if a signal was mapped standalone and as a group signal on different frames of the same cluster
- Click on the "Copy" button didn't have any effect in the ECU Composition Port Prototype list view.
- The "Adapt Connected Port Prototypes" functionality created invalid AUTOSAR 4 constant references
- DaVinci DEV crashed when deleting a record element constant which contained duplicate elements
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
 
DaVinci Developer Version 3.5 (SP1)
Tool features
- Support for interrunnable variables with complex data types
Fixed issues
- Exported of ECU-Extract contained invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters or frames
- Wrong consistency check messages were shown after the first ECU-C synchronization
- Rte generation failed with "internal error" if the workspace contained Nv ports and the workspace option 'Check and Generate Nv ports' was disabled.
- ComSignal-names were not correctly imported from the ECU-C file for AUTOSAR 3 Multi-ECU or Multi-Config project.
- The Software Component properties dialog cannot be closed if the Internal Behavior element contained a custom name without implementation element.
- The MECU file of Multi-ECU project couldn't be imported if the 'MasterExtract' XML element contained additional elements e.g. comments
- Crash on importing ECU-Extract fixed if End-to-End protections with END-TO-END-PROTECTION-I-SIGNAL-I-PDUS exists in the ARXML file.
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.5
Tool features
- Definition of End-to-End Protection is now supported for ECU internal connections
- Enhanced workflow support for the merge use-case: new Project Merge Assistant functionality available in the explorer context menu of a .dpa file
- Support of Nv Data Interface and Nv Block Component Types in AUTOSAR 3
- The SYMBOL property is now supported at the Software Component Type
- For the online calibration the 'RAM buffer size' is configurable under Generation Parameters
- Description at the COMPU-SCALE object is now supported
Usability enhancements
- Setup of a new Project Assistant project will now create standard End-to-End Protection generation calls in the Generator list
- DaVinci Developer component registration within Windows using the DaVinci Installation Manager is no longer required. Thus administrative rights are only required at setup time and no longer at runtime.
- Large performance enhancement when merging software components with the 'Check differences before import' option
- ECU Project report now contains more description fields
Fixed issues
- Non-ANSI characters were located in the standard data type description; they are removed now.
- The setting for 'UsesE2EProtection' will now always exported into XML, even if set to FALSE
- Importing an existing AUTOSAR 4 port interface with a different 'IsService' setting no longer throws an exception
- Creating a new AUTOSAR 4 project no longer throws an 'missing package reference' error when adding a new port prototype to the ECU Software Composition
- AUTOSAR 3 import merged CompuMethods with the same name and package even if they were not equal
- DVImEx command line tool didn't report an error if the specified item couldn't be found
- Removing packages which were used within a ECU software composition didn't throw an error
- Using 'Substitute missing objects' import option caused an exception if an application data type was resolved with a workspace element
- The default package assignment during import was not correct for CompuMethods and Units
- AUTOSAR 4 communication update removed an existing LIN cluster
- Generic attribute export was missing for port prototypes at the ECU software composition
- AUTOSAR 4 export aborted if an inconsistent port connection existed
- The find function didn't find Enumerators and Record-Elements
- Incompatible standard generator was reported when using command line Rte generator
- Error dialog with message "Failed to create empty document." was shown during ECU Project report containing software compositions
- Timestamp of observed external Service-Components were reset after workspace reloading when using DCF format
- Crash in import dialog if observed Service-Component file were added twice and one of the duplicates was removed
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.4
Tool features
- Automatic mapping of application- to implementation data types
- Configuration of 'Mode Transisiton' runnable triggers is now supported
- Design of pointer data types (DATA_REFERENCE) is now supported
Usability enhancements
- In the software design the Tab-key can be used to step to the next design element of the same type
- Some enhancements in grid alignment of connections and cross-sheet connectors
- Enhanced info message to detect objects in different packages with the same name but different content
Fixed issues
- Creation of circular references within record and array data types is now denied
- Consistency check for missing application data type was only executed during Rte generation but not in the tool
- Importing a data reference which does not specify an impl or target policy hasn't set the SwImplPolicy value to 'standard'
- Rte validation and generation aborted with the message "Could not open file" if the temporary files folder contained too many files following the same name pattern.
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3 (SP5)
Tool features
- Support of Signals has been added which were sent on several frames with several channels of a cluster
Usability enhancements
- Naming of 'Symbol' attribute in data type dialogs has been clarified. The term 'Code Symbol' and 'Short Name' is now used instead.
- Performance enhancement on import/check of data types
Fixed issues
- List display of large number of port prototypes was incorrect when using cursor keys for navigation
- Crash when pressing "n" in the Compu-Method dialog fixed
- The communication specification attributes were incorrectly/not adapted on a destination port.
- Some minor memory leaks fixed
- In rare cases the automatic Data-Mapping switched the sub-element mapping of signal groups
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3 (SP4)
Tool features
- New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU
- Port Defined Argument Values are now available at Application Components
Usability enhancements
- Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
- Init-Runnable annotation is now supported in AUTOSAR 4 Admin-Data export
- Category items in the Library View now have a 'SelectAll' function
Fixed issues
- Editing port accesses using multiple selection led in a dialog error
- AUTOSAR 3 import of enumerations didn't work if an enumeration value had the same name but a different position
- Existing SWC implementation was removed during AUTOSAR 4 import if a SWC with the same name and empty structure was imported
- Internal data constraint couldn't be edit if set to -INF or +INF
- Error message 'item not found' during AUTOSAR 4 import fixed if an existing data type with compu-method was updated without a compu-method
- Wrong export of constant-reference item fixed if it actually didn't reference a constant
- Wrong export of the DEST attribute fixed if the component type is a complex device driver
- The data-constraint reference wasn't saved on closing the dialog with 'OK' after creating a new calibration element prototype
- Crash on re-opening a DCF workspace fixed that was caused by memory leaks
- Name clash fixed during export of End-to-End protections on atomic ports
- The 'Adapt connected port' functionality didn't consider all communication specification values like 'EnableUpdate'
- Consistency check message #40329 'unsupported N:M communication' wasn't displayed anymore
- Mapping of single signal to nested arrays and vice versa didn't work correctly
- Task property 'generate schedule calls' wasn't stored in the ECU-C file
- Invalid ComSignal/ISignalToIPDUMapping references were falsely reported if the corresponding ISignalTriggering didn't reference a signal port
- CalibrationSupport flag wasn't written to the ECU-C file for all atomic software components
- In some cases the 'Find Results' properties opened the wrong property dialog
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3 (SP3)
Tool features
- End-to-End protection resynchronization flags are now supported for AUTOSAR schema 4.0.3
- Data Mapping of single signal to array data types is now supported if the array is part of a complex structure
- Import feature "check for differences" is now available for AUTOSAR 4 Software Component Types
Usability enhancements
- Misleading general import message "Ignoring internal data constraints" is now replaced with a more specific one if the data constraints are incompatible
- Starting from an existing port it is now possible to create a foreign port, including a necessary connection
- Copy&Paste of Data-Element-Prototypes and Port-Prototypes is now supported from one interface/component to another
- The automatic data mapping has been enhanced to match sub-strings with the biggest possible string length
- The 'adapt connected port' function has been enhanced with additional options
Fixed issues
- The default package path assignment to CompuMethods and Units was wrong
- The properties button in the data selection dialog didn't work for AUTOSAR 4 data types
- Wrong import of indexed elements (e.g. Record-Elements) has been fixed if the elements have temporarily the same name during import process
- Import of Revision-Label at the InternalBehavior element was missing
- Consistency check was not correctly executed for Calibration Communication-Specifications
- The item locking state was not corrected stored for packages in DCF workspaces
- In ARXML export of DCF saving the generic attribute IMPORT_MODE_PRESET was missing at the ECU-SW-Composition delegation ports
- When importing an updated ECU-Extract an existing LIN-cluster was deleted.
- If the delegation port of an ECU software composition was inconsistent the ARXML export aborts with error message 'Internal exception occurred: The connection is missing a valid transmitter or receiver port'
- The Runnable Operation Access was not imported using a AUTOSAR 4 SoftwareComponentType in "overwrite" mode
- The Component Type dialog not forbids setting the 'supportsMultipleInstantiation' flag for Service SWCs.
- Internal exception during ARXML import has been fixed if an application data type was resolved using a workspace element
- The package import mode workspace and session setting was ignored by the ARXML import dialog. Thus it always selected the package import mode 'import from file'
- The ModeDeclarationGroups dialog was not correctly updated when explicit values of a mode have been changed
- The color highlighting of compatible ports was not consistent during manually drawing of a connection
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3 (SP2)
Tool features
- Cross-Importer is now available to import AUTOSAR 3 software components into an AUTOSAR 4 workspace
- End-to-End protection resynchronization flags are now supported for AUTOSAR schema 3.2.2 and 3.2.1
- Calibration communication specifications are now supported on Compositions too
Usability enhancements
- Constant selection dialog now additionally displays the constant value
- Workspace format has now to be chosen explicitly when creating a new workspace
- Some consistency checks have been enhanced to detect usage of identical names that lead into Rte generation errors
- XML-Importer Output messages have been improved to display more context information
- Separate consistency message details dialog has been replaced by an in-place display in the messages tab
Fixed issues
- "Save As..." didn't work if .dev workspace file was set to read-only
- Consistency check ID 20013 was thrown on invalid argument prototype which was not visible in the GUI
- Cryptic open workspace message was shown in the action log when using DCF workspace in a DPA project
- Item information was missing in the data type unit check message
- Find functionality didn't fully support AUTOSAR 4 types
- Obsolete menu entries appeared in AUTOSAR 4 design mode
- AUTOSAR 4 PARAMETER-PROVIDE-COM-SPEC was is not exported
- COM-Callbacks couldn't be configured depending on the 'enabledUpdate' setting
- Several problems concerning missing elements have been fixed in the AUTOSAR 4 import/export
- Crash in converting old .dev workspace fixed if inconsistent objects exist
- AUTOSAR 4 EcuAbstraction- or ComplexDeviceDriver were imported as services even if they used application ports
- AUTOSAR 4 import with "Substitute missing objects" didn't work with mode declarations
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3 (SP1)
Tool features
- The 'Enable Update' is now supported at the communication specification to configure the Rte_IsUpdated functionality
- N:1 Sender/Receiver Intra-ECU communication is now supported in case no internal senders were used
- Reporting of ECU Extracts and Software Components is now fully available for AUTOSAR 4
- ARXML export in schema version 4.0.2 is now available
Usability enhancements
- Definition of record order index can now be simply configured by moving the elements
- A separate icon has been introduced in the graphic for Nv Data Port Prototypes
Fixed issues
- Wrong check message for open delegation R-Ports without init values has been fixed
- End-to-End protection information was not fully imported/exported for AUTOSAR 4 format
- The option ''Overwrite import mode preset' didnt work for AUTOSAR 4 import
- The 'create port prototype' functionality in the data mapping view failed with the message 'invalid pointer 0x80004003' when using signal groups
- A new workspace couldn't be created based on a Multiple Configuration project setup
- Superfluous Operation Argument Prototypes were not deleted when importing an ARXML file
- An invalid ARXML file was exported if the configuration contains diagnostic communication needs
- A modified software component graphic was not stored if the component type was locked during the graphic editor was open
- New calibration element prototypes could only be created by pressing 'Apply' in the dialog and not with 'OK'
- The properties window didn't display the signal attributes of the selected network signal in the data mapping view
- Multiple Configuration files couldn't be imported because the XML import dialog reported that the selected *.imc/*.mecu file was not supported.
- Unconnected Calibration Ports caused a Rte generation error
- AUTOSAR 4 export wrote lots of empty XML element tags
- A check was missing to report that a Service Mapping should not allow N:1 Client/Server communication
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
 
DaVinci Developer Version 3.3
Tool features
- Workspace design mode: AUTOSAR 3 or AUTOSAR 4
- Import/Export of AUTOSAR 4.0.3
- Import/Export of AUTOSAR 3.2.2
- Support of DaVinci Configurator 5 projects: hide RTE configuration features
- Import of frames with multiple frame triggerings
- Selective import (communication only)
- AUTOSAR 4- Support of data type model (Application Data Types, Implementation Data Types, Base Types, Type Mapping Set)
- Definition of constants as value without type reference
- Compu Method, Unit and Data Constraint as library objects
- Selection of included data types in context of a component type
- Selection of data constraints and handle-invalid settings for data element prototypes
- Local definition of init values constants in the communication specification
- Definition of symbol for component types and data types
 
- AUTOSAR 3- Support of NV Data Interface
- Support of Daimler E2E profiles
 
Usability enhancements
- Import Dialog: display AUTOSAR version of selected files
- Import Dialog: allow import of a file set with differing AUTOSAR minor versions
- Allow unconnected delegation ports (info instead of error message)
- Allow unconnected calibration R-ports
- Init value can be omitted, if the init value is defined at the connected port
- AUTOSAR 3: Display resulting physical range of a data type depending on the scaling
Limitations
- For AUTOSAR 4 design the following functionality is currently not available:- Create Port Prototype from data mapping based on a given signal
- Adapt Data Type for Data Element based on a given signal
- Find unused data types
- Reporting of ECU-Extracts or Software Components
 
DaVinci Developer Version 3.2 (SP7)
Tool features
- Maximum enumerator name length has been increased from 255 to 32767 characters
- Support of Signals has been added which were sent on several frames with several channels of a cluster
Fixed issues
- In rare cases the automatic Data-Mapping switched the sub-element mapping of signal groups
- It was falsely allowed to add a second composition to an ECU-Project using Drag&Drop
- The Library's package view was not updated when creating a new root package within the package selection dialog
DaVinci Developer Version 3.2 (SP6)
Tool features
- Support of UUIDs on import/export at additional elements has been added
Usability enhancements
- Automatic service mapping has been enhanced to get better sub-string name matching
Fixed issues
- Autoconnect popup menu was corrupt and contained empty and wrong entries
- Option to show strict compatible ports only must be toggled to had an effect
- Rte code contained a wrong com signal (group) handle: the handle of a transmitted ComSignal is used instead of the handle fo the received ComSignal.
- A DCF workspace couldn't be opened anymore due to invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters/frames
- Error message "Invalid pointer code 0x80004003" was thrown when using "Create Port Prototypes"
DaVinci Developer Version 3.2 (SP5)
Tool features
- Task Mapping has been improved to read the Schedule Manager configuration from the ECU-C
Usability enhancements
- Performance enhancements during loading/saving DCF workspace and ECU-C synchronization
- Automatic data mapping has been enhanced for Group-Signals with better name matching
Fixed issues
- Copy&Paste keyboard support (Ctrl+C and old Ctrl+Ins, ....) was missing in the output window
- Consistency check crashed in rare cases if the model contains unresolved references, e.g. caused by an import of an inconsistent ARXML file
- Calibration-Access of queued communication was exported with the wrong default value which should be 'not accessible'
- Misleading Action-Log message: 'CONTAINER /ActiveEcuC/Os/osSystemApplication: Os resource reference /ActiveEcuC/Os/RES_XYZ could not be resolved.' was reported
- Closing a dialog with "Cancel" initiated superfluous GUI updates on unmodified data
- 'Adapt Data Element to Signal' or 'Create Port Prototypes' falsely modified the record element order
- A software component was displayed twice in the graphic when dropped into a composition
- Export of ECU-Extract contained invalid SIGNAL-MAPPING elements if a system signal was received and transmitted on several clusters or frames
DaVinci Developer Version 3.2 (SP4)
Tool features
- New Data Exchange Analysis view in the ECU-Project to get an overview of the resulting port data exchange, operation invocation or signal flow within the ECU
Usability enhancements
- End-to-End Protections can now be re-assigned to another port and remain existent if the Data-Element-Prototype is removed
- During data mapping an existing data type is now automatically reused in the 'Create Port Prototype' functionality if the name and primitive types matches the new mapping
- The selection in the data mapping editor now remains, when opening and closing the 'Create Port Prototype' dialog
- Drag&Drop of multiple selected ports have been enhanced to keep their left/right position
- Delegation Ports can now be located automatically when positioned on several sheets and shifted to a sheet manually when unconnected
Fixed issues
- Crash in generic data selection dialogs fixed if the dialog was closed with a double-click without a selected item
- The Copy&Paste command from the context menu didn't work in the library window
- The RTE Generation aborted with the error 'An entry with the same key already exists' when an Application Error of an Operation Prototype was not uniquely named
DaVinci Developer Version 3.2 (SP3)
Tool features
- Display and edit of Port-Access and Trigger Short-Names of runnables are now available in the GUI
Usability enhancements
- Create ports from signals now allows direct specification of packages for the newly created objects
- ECU-Project and SWC report has been enhanced to display description fields
- Trusted functions, which weren't added by the RTE (without the 'Rte_' Prefix) are no longer displayed as error in the ECU-C synchronization difference view
- ARXML import performance using ''substitute missing objects' option has been significantly improved
- Separate consistency message details dialog has been replaced by an in-place display in the messages tab
Fixed issues
- Incompatible standard generator was reported when using command line Rte generator with an ECU-Project that didn't contain a generator definition
- Crash occurred while loading ECU-C file of a DCF workspace if the ECU-C file was split into module specific files but the main ECU-C was empty, i.e. all module definitions were missing
- Error dialog with message "Failed to create empty document." was shown during ECU-Project reporting if it contained hierarchies of Software-Compositions
- Button on a background view falsely worked on currently active view if two overlapping software component views were opened
- The info message (40288 DataType with the same name as a platform type) created for a DataType/Constant was propagated to the SWC as an error
- VFB Trace functions weren't correctly stored in DCF format if no other workspace modifications have been done.
- Crash occurred when importing an incomplete AUTOSAR file containing a SYSTEM but neither an ECU-INSTANCE nor an ECU-SW-COMPOSITION
- DVImEx didn't report a message when the specified item was not found in the data
- The find function didn't find Enumerators and Record-Elements
- The GenerateStub setting was overwritten even if a user configured value exists
- The operation call return trigger was removed from the ARXML if several runnables were triggered by the same operation call return trigger.
- Group-Signal selection for data mapping didn't show signals if the data mapping view is in 'Data-Element' perspective
- Connection was deleted during ARXML update although one of the connected port prototype's import mode was set to 'keep'
DaVinci Developer Version 3.2 (SP2)
Tool features
- Configuration support for End-To-End Protection resynchronization added
- Configuration of Rte generation parameters is now also available for Service Components
- Workspace checker command line tool got the new option '-s' to save the check modifications to the workspace
Usability enhancements
- Enhanced display of consistency check messages to allow grouping of similar messages by their ID
- ARXML import dialog now allows import of multiple files with different AUTOSAR 3.x schema versions
- Data type dialogs now display the physical ranges according to the configured scaling information
- Graphical Cross-Sheet Connectors now display the full port name with Component Prototype context
- Delete objects of different types with multi-selection is now supported
Fixed issues
- Memory leaks removed when loading/saving DCF workspace
- Port interfaces without data element prototypes caused empty element tags in the exported ARXML file
- Using the filter in the object selection dialog removed the package display
- ECU Project graphic display caused a memory corruption
DaVinci Developer Version 3.2 (SP1)
Fixed issues
- Loading a DCF workspace aborts with error message "Unknown Interface" if an obsolete task mapping was defined in the ECU-C file that refered to a deleted runnable or a deleted task
- Rte generation aborted due to inconsistency warnings threw by the Rte generator, which were tolerable in specific cases
- Rte generation aborted due to inconsistent record constant structure
- ARXML import crashed if a Signal-Group and a Signal caused a namespace conflict
- Missing object references in the ARXML file couldn't be resolved with existing workspace objects using "check for differences" option. This option is now disabled because "substitute missing objects" cannot be used when merging the objects.
- USB dongle access caused GUI freeze in some situations
DaVinci Developer Version 3.2
Tool features
- New Software Component Type to define End-to-End Protection Proxy Components
Usability enhancements
- Additional export Option added to omit the End-to-End Protection Configuration in the exported ARXML
Fixed issues
- Import of ARXML packages had overwritten existing package content instead of merging it
- Multiple Configuration projects couldn't be created if different package structure exists in the input files
- Root package could be illegally moved into an existing package structure that results in a deleted package even if the workspace wasn't saved
- Signal and Signal-Groups weren't allowed to have the same name. This limitation has been removed.
DaVinci Developer Version 3.1 (SP4)
Usability enhancements
- "Unmap Signal" in the context menu of the Data-Mapping view now supports multi-selection
- Rte trigger and runnable offset properties are now displayed in the properties view when selecting a task mapping table cell
- The "Show ..." option settings in the Data-Mapping dialog are now remembered between dialog sessions
- Multi-selection is now supported for complex constant values via In-Place editing
- Enhanced check for unique C-Symbols in generated Rte code to detect name inconsistencies prior to Rte generation
- Import dialog options are now persistently stored in the workspace to restore them as default on the next dialog session
Fixed issues
- Factor and offset of a data type scaling was mot imported if the ARXML didn't contain a denominator definition at the CompuMethod
- Modification of read/write generic attributes cannot be stored because the Data Element Prototype was read-only
- Loading DCF workspace consumed large amount of memory
- DataSendCompletionTrigger caused a missing Rte-Event reference error in the ECUC-Sync dialog.
- ECU-Project report didn't work for read-only workspaces
- Create DPA project out of existing files failed in DaVinci DEV if no workspace was selected
- Graphic was missing in the HTML report for newly created software components
- Rte generation ran out of memory when using huge complex data types
- The user defined block size on the NvNeed was not used for the ECU-C Synchronization. Instead a wrong calculated value was used.
- DCF workspace save was prevented by check message due to inconsistent import
- Adapt data element to match signals was not available for complex types
- Import of record constant caused unresolved reference error if obsolete record elements were referenced
- Under some circumstances newly created elements didn't get unique names within their package namespace
- The special import 'Overwrite import mode preset' didn't work with read-only items
- Manual service mapping allowed creation of redundant connections
- Import aborted with COM-error 'Invalid parameter' due to an unsupported encoding
- Adapt port prototypes function didn't copy the E2E and HandleNeverReceived settings
- DaVinci DEV runs out of memory because of memory leaks when saving DCF workspace. For DaVinci DEV 3.1 SP4 some leaks have been fixed but there still exists some more that will be fixed in a later version.
Limitations
- AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.
DaVinci Developer Version 3.1 (SP3)
Tool features
- Report generator for ECU Projects and Software Component Compositions
- Full import of communication data from ECU-Extract defined with AUTOSAR schema version 4.0
Fixed issues
- Tool crashed because incompatible newer workspace could be opened with older tool
- Import aborted with "unknown error 0x80004005" if the ARXML file was located in a path containing Japanese characters, e.g. a folder on the desktop
- Some consistency check messages were not displayed in the messages tab after Rte code generation
- If the workspace was read-only the code generation couldn't be started because the generation dialog was read-only too
- USB dongle access caused GUI freeze in some situations
Limitations
- AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.
DaVinci Developer Version 3.1 (SP2)
Tool features
- Import of Software Components and ECU-Extract defined with AUTOSAR schema version 4.0
Usability enhancements
- Better performance and improved layout of Software Component report
Fixed issues
- First service mapping was not displayed in the service mapping tree if more than one mapping information exists
- If a package has been moved within the package hierarchy the saving of a DCF workspace didn't save all package related items. This resulted in an error on loading the DCF workspace.
- Snapshot of a newly created DCF workspace didn't contain read-only information of data-types
- Workspace modified flag had been reset after creating a snapshot
- DCF workspace was not properly saved if a packages was renamed
- Properties view didn't display information for Atomic-Prototypes
Limitations
- AUTOSAR 4.0 import is only possible for software components that don't use AUTOSAR 4.0 specific design features. I.e. only AUTOSAR 3.x related design features are supported.
DaVinci Developer Version 3.1 (SP1)
Fixed issues
- DCF workspace couldn't be loaded due to an AUTOSAR schema violation if item short-names started with an underscore or a number
- Error message "Type library is not registered" was thrown on opening a workspace when DaVinci Developer 3.1 and 3.0 were installed in parallel on the same PC and an active 3.0 installation has been switched to 3.1 using the DaVinci Installation Manager
- Component Types were missing on DCF loading because of ambiguous names within a package
- It was unable to rename an item if the name differed only in character case
- ARXML export using DVImEx failed with workspace read-only error if DVImEx was started from within DaVinci Developer to export from the currently opened workspace.
- Rte synchronization was started even if the workspace was inconsistent
- Invalid record constant has thrown an "Unknown pointer" error during the consistency check of an ECU-Project
DaVinci Developer Version 3.1
Tool features
- Report generator for Software Components
- Support of AUTOSAR Byte-Arrays as primitive data-type
- Support of AUTOSAR Packages
Usability enhancements
- Specific Hex-Editor dialog to define string constants with non-printable characters
- Network signals without frame-mapping can now be used for data-mapping
Fixed issues
- Tool crashed during ARXML import into DCF workspace if the workspace files are read-only
- Rte generation failed if Signal-Group degradation with internal and external receivers existed
- No more error during backup restore after Project Assistant update, caused by the workspace still being used by DaVinci Developer
- Command line Rte generator falsely used the Rte Generator defined at the ECU-Project in the workspace
- An error dialog was missing when a constant was about to be deleted in the Library-Browser which was still in use by a signal
DaVinci Developer Version 3.0 (SP5)
Tool features
- Support of AUTOSAR schema version 3.2.1
- Introduction of object locked state to specify objects as read-only for tools editors and ARXML import
- A Port-Terminator has been introduced to distinguish between intentionally and unintentionally unconnected ports
- Configuration of the 'Handle Never Received' flag at the receiver communication specification added
- Configuration of the 'Uses End-to-End Protection' flag at the sender/receiver communication specification added
- Configuration of the 'Calibration Access' at the argument prototype of client/server port interfaces added
- End-to-End connections are now allowed for mixed internal and external receivers
- Service Software Component files can now be added to an observation list at the ECU-Project to automatically detect file modifications
- Creation of Support Request Package can be started from File-Menu to pack support relevant information into a ZIP-File
- Additional End-to-End Protection profiles to configure specific safety wrappers
- In the Task Mapping a dedicated timing requirement can be configured at a task, to ease the configuration of timesliced systems
- Difference Analyzer is now able to optionaly display added / removed / equal objects instead of displaying the differences only
- Workspace snapshots can now be created at any point in time to store intermediate copies of an open workspace. By restoring a snapshot the content of the workspace is rolled-back.
Usability enhancements
- New option in ARXML import dialog to resolve open references in ARXML files against existing objects in the workspace
- Depending on the 'allow generation of unsaved data' setting and the version compatibility of the RTE the user will be asked if the workspace should be saved and then automatically continue with the current action.
- If the "Synchronize workspace with ECU-Configuration file when loading a workspace" is deactivated an additional message is now shown if the ECU-Configuration file has been changed while DaVinci DEV was closed.
- When creating a Schedule Manager task in GENy, DaVinci DEV now automatically assigns the role "BSW Scheduler" to this task
- Generation dialog has been reworked to show more detailed generation process and error display
- A configurable check has been added to detect if the Invalid-Value lays within the Data-Type Range
- To allow an import, ServiceSWCs are converted automatically to ComplexDrivers if used in a regular Composition
- The command-line importer can now handle several ARXML files in one import step
- Harmonized the XML formalization of the ECUC-file in all Vector AUTOSAR tools
Fixed issues
- An error message was thrown when selecting a huge number of files (> 1000) for import in the file open dialog
- The modification state of the ECU-C file was checked too often under Windows 7
- Port defined argument values with the same name couldn't be imported at different ports of the same software component
- The category attribute was not exported at the CompuMethod
- AUTOSAR XML import aborted with "item is read-only" message if an object with the same name was part of several AUTOSAR XML files and defined in different AUTOSAR packages.
- Mapping of ECU delegation ports was missing in the exported ARXML if the port was not connected to a component type
- Tool crashed when the Software Design was opened after referenced port has been removed during ARXML import
- Color Highlighting of compatible ports in the structure graphic didn't work correctly with several instances of the same Component Type
- Init value specification at Calibration Parameter Com-Spec was ignored in consistency check and Rte code generation
- Different interpretation of file order in the Multiple-ECU overlay file causes error in ECU-C synchronization
- On certain unresolved references to Mode Declaration Groups or Modes itself the import was aborted
- The consistency-check for ambiguous short names in the exported ARXML is no longer case-sensitive
- When the short name of a child element was removed or not unique the according message dialog might have reappeared endlessly
- The OSApplication assignment to a Task is now stored in the ECUC-file even when no other OSObjects can be determined due to consistency errors
- Checking of differences during ARXML import aborts if ModeExecutionInhibitor objects are defined at the runnable
- Wrong error message in data mapping compatibility check has been thrown if the first record element was not mapped to a group signal
- In some cases the DCF workspace save runs out of memory if the software component structure of the ECU-Project contained lots of Compositions if a deep hierarchy
- The use invalid flag and scaling flag at the data types were not reset during import if there was no semantics information defined in the ARXML file
- In rare cases DaVinci DEV crashed during ECU-C synchronize if a port prototype has been deleted while it was referenced by a Data-Reception-Trigger.
- XML Parser error was thrown on Service Component update if an observed Service Component ARXML file was deleted
- Reference to an AUTOSAR constant couldn't be resolved using an existing constant from the workspace
- Com-Callback was missing for the "handle never received" and "End-to-End protection IsUpdated" use case
- Misleading inconsistency message was thrown on ECU-C synchronization if NvM configuration was out of sync
- Rte generation was always aborted even if the stop button has not been pressed in the current generation process
- ARXML import of a complex constant produced an 'Unknown Error' the referenced complex data type was imported from a different file
- Generated Rte code was invalid if a predefined standard data type was renamed to a predefined platform type, e.g. UInt32 -> uint32.
- In case of a split ECU-C project the Rte/NvM/Os module configurations were accidently added to the central ECU-C file and to the module specific ECU-C file.
- Template- and Contract-Header generation from the SWC-context menu didn't work for DCF workspaces
- The ARXML import in mode 'Overwrite' crashed due to an unresolved reference to a Mode-Declaration-Group
- Diff/Merge didn't import Port-API Options correctly
- ARXML import crashed in resolving missing reference by the substitute functionality
- Consistency check message 40231 was thrown because of wrong offset calculation
- In rare cases creating a new workspace crashed on Windows 7
DaVinci Developer Version 3.0 (SP4)
Tool features
- Definition of End-to-End Protected connections available at the ECU project delegation ports to enable external generation of safety wrappers
- Port defined argument values (PDAV) can now be edited at the service component ports
- Enhanced compatibility with MICROSAR RTE generators allows usage of previous Rte version 2.17.2 (and newer) as external generator for this DaVinci Developer release.
 You can find a detailed overview with the compatible MICROSAR RTE versions at www.vector.com/rte_davinci
Usability enhancements
- Icons of the various DaVinci tools got a unique abbreviation to differentiate the tools more easily
- Check message export function has been enhanced with the detailed description and respects now the sorting order as specified in the list view
- Creation of mapped signal ports can now additionally create Software Component ports and connect them to the created ECU-Delegation port
Fixed issues
- ARXML import of complex Data-Mapping was incomplete if an array data type to a signal group contains or is contained in another complex data type
- ARXML import of complex constants with CONSTANT-REFERENCEs was not correct
- Update of existing workspace with an ARXML import failed if a referenced Port-Interface or Mode-Declaration-Group was missing in the ARXML file
- If a service server port is mapped to a client port, it was not possible to map the port from the server side to another client port
- Consistency check of delegation connector ComSpec on ECU top-level was missing
- Consistency check #40259 created an inconsistency message even if the error trigger was correctly used with invalid handling
- Automatic creation of ports in data mapping failed in case of partially received signal group
- Consistency violation reported if scaled signal was mapped to an opaque data element
- Connectors in connector prototype list view were missing if a connector merge scenario was designed
- Relocation of a connection to a compatible delegation port was not visible due to missing graphic update
- DaVinci DEV freezes on certain handlings in the graphic if a large graphic model without sheets is designed
- Connection inconsistency error occurred due to wrong model update when changing the Component Type of a Component Prototype
- Service Mapping didn't show compatible ports correctly when using the 'show compatible Ports only' option in the selection dialog
- In some cases an error message was thrown during import update of LIN cluster with Sporadic Frames
- Import of Port Defined Argument Values with the same name was not possible
- Superflous COM_SendSignal calls existed in Rte code if the same System-Signal was mapped to several Tx/Rx-Frames
- Wrong consistency check message fixed that the Rx-Signal bit length didn't fit into the data element
DaVinci Developer Version 3.0 (SP3)
Tool features
- Microsoft Windows 7 is now supported
- DaVinci Installation Setup now allows maintenance of an existing installation and installation of a new instance in parallel with the same Service Pack version
- Parameter for RTE online calibration can now be configured in the context of the 'Generation Parameters' View
- Enhanced handling for Signal-Groups to allow that a receiver of a Signal-Group / complex Data-Type receives only a subset of the data
- DaVinci Project Assistant now supports setting up projects on DBC, LDF, FIBEX files that will automatically converted into an AUTOSAR ECU-Extract
- DaVinci Developer can now work on ECU-C files which are split into module specific files to allow different users to work on different modules in parallel
- Extension of Multiple-ECU support to explicit overlay Tx/Rx signals and allow PDU overlay of PDUs with optional signals
- New dialog for automatic connection of ports with enhanced matching algorithm and selection of desired connections in prior to apply the auto-connect
- For Project Assistant projects the DaVinci workspace format can now be changed from DEV to DCF and vice versa
- New command-line tool DVWspChecker, which allows consistency checking of an ECU-Project or Component-Type in the specified DVW- or DCF-workspace
- New configuration option to disable the init value check for unused ports (without port-access and without calibration parameter).
 IMPORTANT NOTE: disable the check requires MICROSAR RTE version 2.17.2 for correct code generation
- DaVinci Project Assistant now support creating of projects based on existing non-DPA projects and creation of DPA-projects with module-split ECU-C files
Usability enhancements
- Ports list view is now available for ECU Software Composition
- OS-Counter parameter will now initially set to Os/SystemTimer when creating new Alarms
- Consistency message results can now be exported into a log file
- DaVinci Project Assistant menu and Model Check menu is now available even if ECU-Project sub-items are selected
- Service mapping update no longer closes the complete editor tree after editing service mappings
- Graphical connections are now highlighted when selected a port or a cross-sheet connector
- Navigation in Software Design editor is now possible by clicking on a delegation port
Fixed issues
- Float number format in ECU-C has been adapted to match format used in DaVinci Configurator Pro and GENy to avoid file differences
- Fixed importing an ECU-Extract using the Diff&Merge feature to avoid corrupted communication information due to wrong merge algorithm
- ECU-C file consistency dialog no longer opens up when saving the workspace
- Obsolete check message is no longer displayed after fixing an inconsistent Data-Element-Prototype at the Component-Type's port
- Errors message for unconnected ports and non-matching Data-Element-Prototypes are now split into separate specific messages
- In some cases the DaVinci DEV application couldn't be closed through the task-bar menu
- Alive timeout handling was falsely enabled if the value was set to 0.0 instead to 0
- In some cases an editor update was missing on creation/deletion of runnables
- Service Need names were not checked for uniqueness
- ComSignal(Group)s were not found in ECU-C in the Multiple-ECU configuration of PDU as Overlay-PDU which contains optional signals in the master ECU-Extract.
- File version checking of the MECU schema version has been corrected
- During ARXML import the remember-option is now disabled on special import mode condition, if only new-mode is allowed
- RteEvent references will now correctly resolved if ECU-C uses short names with 32 chars but ECU-Extract uses short names with 128 characters
- DCF load aborted when the DCF AUTOSAR version was different from the ECU-C AUTOSAR version
- In some cases DEV requested an ECU-C lock although it was not the active application
- Bugfix in the placeholder replacement of $(GENDATAFOLDER) when the following character is a double quote
- ECU-Project consistency check crashed if several runnables exist which were triggered by an OnModeEntry event
- AUTOSAR Import/Export ignored the Communication-Specifications at the ECU delegation ports
- Missing popup menu entries at ECU-Project Connector-List editor for changing port prototypes
- Installation setup has defined wrong working directory entry in the DaVinci Developer desktop link
- ARXML import created Enum-Types without enumerator instead of Integer-Type if the scaling at the data type had defined an own range
- DCF workspace couldn't be saved if multiplexed communication was used
- DaVinci Difference analyzer stopped with error 0x800407D0 in XPath Expression at xsl:if "Too many items - string" if calibration parameter init values were defined
- In rare cases the ECU-C synchronization moves the ECU-Configuration tag in the ARXML file if a module configuration (e.g. of a 3rd Party module) in the ECU-C file exists, that has a Short-Name that comes in the alphabetical order before the 'ActiveECUC' Package.
- ARXML import aborts with E_FAIL error code when importing renamed record data-types referenced by record constants
- Wrong ComSignal handles in Rte because ARXML import didn't update the message to signal relation correctly in overwrite import mode.
- Main window could not be restored if it was minimized running on Windows 7
- Wrong Init-Value consistency check message was reported if obsolete communication specifications existed
- Wrong display of some dialog controls on Chinese Windows has been corrected
- Auto-Connect created a connection between C/S and S/R which resulted in a consistency error
- Auto-Mapping has created wrong or inconsistent signal group mapping if naming rules and compatibility of elements was ambiguously
- If NvM memory blocks were configured and the according NvM service component was imported the consistency check may have been crashed.
- Rte callbacks were missing if the same system signal was mapped on Rx and Tx port
- Response on GUI actions was very slow and had 1-2 seconds latency when using Vector USB Dongle license
- Setup threw an error message that product isn't installed when using the repair option
- Constraints and Limits properties of the data element prototype were ignored when importing
- In rare cases DCF load restored a wrong order index of the Task-Mapping
- Unintended message was shown if the ECU-Configuration file has been changed while closing DaVinci workspace
- Top-Level connections were not correctly removed during ECU-Extract update
- Obsolete ModeDisablingDependencies were not removed correctly during import
- Import of Multiple ECU Extract aborted with 'Item already in Set' error
- Save Workspace As failed, if the workspace was read-only because it was created with a newer DaVinci version.
- ARXML import of incorrect MODE-DEPENDENCY aborted with "Unknown error" instead of printing an error message
- Special import feature couldn't be executed if a Project Assistant file was referenced in the ECU-Project
- An update of an ECU-Project failed with the message "Invalid argument" if a mapped Per-Instance-Memory wasn't overwritten due to the Import-Mode-Preset attribute
- Import of incorrect EXCLUSIVE-AREA-ACCESS aborted with "Unknown error" if the references to the exclusive area was invalid
- If the P-Port was a delegation port of a SW-Composition it was unable to connect an R-Port because of wrong incompatible direction error message
- If multiplexed ECUs exists the DaVinci DEV added ComSignal callbacks to the ECU-Configuration but the functions are not generated by the Rte generator
- Rte generation failed with an internal error if an ARXML with multiple mapping of the same system signal has been imported in prior
- After loading a DCF workspace the data mapping was lost for delegation ports which received a subset of a signal group
- ARXML import crashed if LIN event triggered frames were imported
- Import-Mode-Preset attribute didn't work for Mode Disabling Dependencies and port related triggers in the 'keep' use-case
- Save workspace in DCF format didn't work if BSWMD files with command line macros are specified in the ECU-Project
- OS Application dialog crashed on editing an existing OS Application if more than one OS Application is defined for a task
- A signal was treated as received through a frame although no rx relation existed. This results in an incorrect ECU-C synchronization because the signal was actually not used on Com layer
- Rte generation was wrong because Rx signal relation was missing for Tx/Rx signals sent between two instances of a Multiple-ECU project
- Calibration port init values were not correctly updated on ARXML import of existing software components
- Graphic update was missing if 'complete delegation port' has been executed in a separate view
- Data mapping was not imported/updated correctly in ARXML import of a Multiple-Ecu configuration with complex data types
- Data mapping was lost on loading DCF workspace if not all data elements of a delegation port were connected to an atomic port prototype
- USB dongle access caused GUI freeze in some situations
DaVinci Developer Version 3.0 (SP2)
Tool features
- Support of AUROSAR schema version 3.1.4 and 3.0.6 in import/export and ECU-C synchronization
- In addition to importing an ECU-Extract of System-Description the import of a System-Description containing more than one ECU is now supported by selecting the ECU to import
- RTE measurement supported by specifying the according parameters at the Calibration Elements, Calibration Parameters, Inter-Runnable Variables, and in the global generation parameters
- Specification of an Rx-Filter is now possible at the receiver communication specification
- Minimum start interval can now be specified in the runnable properties
- Double data mapping for a signal is now allowed if the Tx/Rx direction differs, i.e. the same signal can be used as sender and receiver
Usability enhancements
- Newly created ECU projects using the DaVinci Project Assistant now contain default entries for generators/configurators
- Automatic creation of server runnables can now be configured with an additional pre- or post-fix for the runnable name
- New feature in the signal data-mapping editor to create ECU delegation port prototypes, which matches the Tx/Rx-Signals of an ECU project
- ECU-C file synchronization no longer requires a specific AUTOSAR package structure
- Graphic export to the Windows clipboard can now be initiated with Ctrl-G. Graphic file export now supports exporting of all Sheets in one step.
Fixed issues
- Multiple instantiation of service components in the service mapping editor is now prevented
- Wrong consistency check message about overflow in 64 bit data type range fixed
- In some dialogs the edit controls were disabled instead of read-only which inhibits copying of the text content
- Unexpected additional enumeration data type was created during ARXML import if COMPU-CONSTs exists for non-integer data-types
- Missing consistency check for init values at the port's communication specification if two SWC receiving the same signal, but the port interfaces have different init values
- Inconsistent rounding of imported values in DBC and ARXML with a precision of more than 15 digits fixed
- Consistency check for different receiver invalid handling didn't work for external communication
- Unexpected empty XML element <SD GID="edve:ValRef"></SD> was exported for calibration parameters without init value
- Show reference in object usage dialogs didn't work if the object usage dialog was started on a object from within the search result list
- Changing an ECU-Project's ECU-C-File does not always trigger an ECU-C sync if another tools hold an ECU-C lock
- Updating an ECU-Project with a file that contains frames with equal (case-insensitive) SHORT-NAMEs had failed
- Automatic ECU-C synchronization haven't detected generation parameter changes if the parameters were changed the second time
- ECU-C file couldn't be found in DCF Utility because of using relative paths
- ECU-Project settings couldn't be edited with DaVinci Project Assistant if the DPA file reference contains a relative path
- Import ARXML from path containing Japanese characters failed
- Parameters for Component Implementation Template Generation and Contract Phase Header Generation were mixed up in newly created ECU-Projects using the DaVinci Project Assistant
- Too many ECU-C signals were created if PDU routing is designed when a frame is transmitted but not all signals have a tx relation
- DaVinci crashed when a multi-selection of ECU-Projects is about to be exported to ARXML
- DCF workspace couldn't be saved after modification if a Port-Prototype was deleted which was referenced by a Runnable's trigger
- DaVinci crashed after deletion of the mode declaration group prototype with already used name
- Compiler/Linker error due to inconsistent callback definitions for ports without port access but AliveTimout > 0
- Tx callback was exported for Rx signal if the signal was sent and received on the same network
- Task type was not correctly imported from ECU-C if different Os BSWMD contains a platform specific package
- In rare cases update of an ECU-Project via XML import with ECU-Extract and ECU-C file failed with error message "Item already exists"
- Importing an ECU-Extract using the Diff&Merge feature had corrupted the data mapping if additional signals or signal groups have been added
- Service mapping was missing when exporting service layer components to ARXML or DCF
- Record constants with invalid element order were created based on a Signal-Group
- In some cases the error message "Receivers of the data element prototype <SignalName> handle the Rx-Filter on a different way." was reported even if the Rx-Filter were correctly defined.
- Rte's Com-Callbacks for Signal-Groups use wrong Group-Signal identifiers if a Fan-In of Signal-Groups with mapping different frames of the same cluster exists
- Generated Rte contains several callback functions with the same name if a signal is mapped to one pdu which in turn is mapped to several frames and the Rte has to generate a callback function for this signal
DaVinci Developer Version 3.0 (SP1)
Tool features
- Support of LIN Signal-Groups defined LDF files with the naming convention <signal_group_name>__<signal_name>
- AliveTimeOut is now imported from DBC and can be propagated using a new function in the data mapping view
- The newly introduced automatic ECU-C synchronization during workspace load/save can be switched off in the global settings dialog
- Display of calibration objects in the graphic can be switched off in the workspace settings
- Support of ARXML import pre-configuration using generic attribute IMPORT_MODE_PRESET
- Constant property "Generate Symbol" can now be set in Library-Browser via multi-selection
Fixed issues
- Wrong workspace conversion that causes missing Signal Group references during ECU-C synchronization has been fixed
- Inconsistent connections (wrong sender/receiver direction) were not detected by a consistency check
- Error message in the GUI when changing R-Port's "Handle Invalid" property has been fixed
- Compatibility settings couldn't be set properly in the workspace settings dialog
- DCF Utility didn't show Activation Offsets in the ECU-Project binary file
- Missing check messages on inconsistent data mappings have been added
- Additional name information for "DEFINITION-REF" objects in difference view have been added
- Inconsistent structure of a complex constant compared to its data type have caused a generation error even if the constant was not actually generated.
- Out-of-memory error message occurred in DCF Utility when opening large dcb files
- Missing sorting of FIBEX-ELEMENT-REF in difference view has been fixed
- Crash in DaVinci DEV has been fixed when switching to the ModeDelarationGroups in the properties view
- Show in software design command for runnables in task mapping page didn't work.
- Error Handling for ModeQueueLength '0' has been corrected
- Within the data element prototype page the CreateNewDataType button didn't work
- During ARXML import the renaming a child object didn't always work if the names only differ in character case
- External tool command line parameters are changed back to default if no parameters are given in the dialog
- The consistency check for Calibration Ports has been weaken to allow compatible interfaces that are not identical
- ARXML import failed if existing objects only differ in character case from objects that were to be imported
- Tool crashed when saving new SwBlockNeeds with a mirror PIM that had no data type
- In read-only SWCs the implementation popup menus were not disabled and tool crashes if menu commands was executed
- Tool slowed down after running several hours because of GUI resource leaks
- Wrong setting of working folder in attached files dialog fixed that caused error message while opening generated attached SWC template file
- Generated OSAlarm and OSEvents didn't match because the setting 'use shortnames > 32' was not consistently communicated to the RTE
- Added multiple mapping of the same system signal on one frame to support the multiplexing use-case
- Extended support for Tx/Rx split and signal overlay in the Multiple-ECU use-case
- ARXML runnable import of Init-Trigger corrected if no other Trigger exists
- Fixed error while synchronize structure of a complex constant in AUTOSAR export if the structure of the complex data type has been changed
- Newly created graphic sheet names were not stored correctly in the workspace
- ECU-C file data wasn't fully loaded during opening DCF workspace if the AUTOSAR schema versions have been different
- Generic attribute definitions weren't loaded during opening DCF workspace if a corresponding generic attribute didn't exists at an AUTOSAR object
- Missing error message while opening incompatible workspace with RTE Generator fixed
- Generation of templates and contract headers is now allowed for service components
- Sorting of error/warning/info icons in the messages tab has been corrected
- The initial graphic scroll-bar position was often not correct
- Newly created Port-Prototypes are now automatically positioned near the original port
- Auto-mapping for wasn't working well with multi instance SWC
- Directory placeholders with workspace variables were not working correctly for DCF workspaces
- Service mapping was missing when exporting service layer components to ARXML or DCF
- Property dialog for NvM block needs threw an error when using read-only Component-Types
- Some issues in workspace merger functionality have been fixed concerning communication merge, generic attributes, and data-mapping
- The global attribute definition file in a DCF workspace can now be modified in the DCF-file to share it among DCF workspaces
- The Mode disabling dependencies for runnable triggers were doubled during the XML import
- Task attributes priority / description / schedule were incorrectly loaded from DCF workspaces
- Signal bit length was not updated from DBC file if the signal with data-type reverence already exists
- Service needs were deleted during special diagnostic import
- Bad performance while switching from structure design to port prototype view solved by specifiying the livst view as default editor for non-graphic use-cases
- ECU-C sychronize of Init Values produced unnecessary warning output
- Init value check for the Data Mapping didn't work
- Incorrect Exclusive Area Access after DCF loading if AR 2.1 SWC are used together with AR 3.0 ECU-C file
- Attribute definition inconsistencies weren't reported during DCF loading
- Inconsistent NvM block and PDAV order was not reported by a check
- Signal's unit was not imported via LDF file
- Crash has been fixed while opening ECU Project Software Design editor after large SWC was updated by importing new SWC definition
- Loading of global generic attribute definitions has been restructured to avoid overwriting with local attribute definition during DCF loading
- Wrong consistency message concerning maximum values was displayed due to rounding problems in physical value calculation
- Workspace settings were reset on saving a DCF workspace as DEV
- Read-only ECU-Projects were missing after loading a DEV workspace which was created out of an DCF workspace
- Crash during DCF save has been fixed if many read-only DCF files are about to be stored
- Signal length was set to null after a LDF file has been updated through the ECU-Project signal list
- Data mapping was missing after loading DCF workspace if atomic software components were multiply instantiated within an ECU-Project
- Update icon was not correctly displayed in Attached-Files dialog
- In rare cases DCF save aborted with COM Error 0x80070057 if the ECU-Project contains a large amount of Software Component Prototypes
DaVinci Developer Version 3.0
GUI rework
- New window concept for parallel editing in several views of an ECU project
- Modernized GUI style, icons and tool buttons
- Reworked library browser with additional folders for service related objects
- Reworked software design views to enable multi-editing of object properties
- Clear separation of global user settings and workspace specific settings
- Changed workspace file extension (.dev)
Improved cooperation with DaVinci Configurator Pro
- Project Assistant for convenient creation and update of ECU projects
- Overwrite protection against ECU-C editing conflicts by mutual blocking of the tools
Usability enhancements
- Drag&Drop of component types and port interfaces into structure graphics
- Direct invocation of template/header generation for individual component types from context menu
- More intuitive display of consistency check messages
- Optional display of calibration ports and connectors in structure graphics
- Display of additional info in data mapping editor for fan-in/fan-out signals
- Improved object selection dialogs (display of additional info, enhanced filter logic)
Graphic design improvement
- New layout function: Automatic positioning of delegation ports near the connected port
- New layout function: Vertical/horizontal alignment of components
- More intuitive zoom control via zoom-in/zoom-out buttons
- "Align spread/packed" function available for a selection of ports
Performance enhancements
- Speed-up of ECU-C synchronization
- Speed-up of general XML import/export and consistency check
Merging of design data
- Detailed merge control during import via difference view: overwrite workspace object or keep it
- Fine-grained merge control for complete library objects or individually for each sub-object, e.g. runnable entities and port prototypes
- Merge control setting persistently stored at each object - convenience for subsequent import
Tool features
- Definition of service needs of component types
- Support of complex device driver component types
- Support of LIN signal groups in imported ECU Extract
- Configurable symbol generation of constants
- Definition of limits for calibration element prototypes
- Support of unconnected R-ports and unconnected ports of calibration components
- Definition of alive timeout at delegation port prototypes
- Explicit trigger type "Init Runnable"
- Definition of task type (basic/extended/automatic)
- Definition of task role (application/BSW Scheduler/non-RTE)
- Disabling of automatic trigger generation in the OS
- Search function to find unused objects in the workspace
- Support of invalid values within the range of 0 ... 255 for boolean data-type
- Command line extension for DCF Utility to directly start a DCF workspace difference analyzing from the command line by specifying the 2 workspaces
Fixed issues
- Recent file list was too small
- Under rare circumstances copying of a software component caused a crash because of wrong graphic stream duplication
- Overlay of component prototypes in the Multiple-ECU use-case is now based on the component type reference
- During ECU-C synchronization the task activation value was not considered
- If the first ECU-C synchronization has been done with the direction from ECU-Project into ECU-C file existing COM-Signals were duplicated in the ECU-C file
- In some dialogs the display of the description contained non-printable line-feed characters
- When saving a DCF workspace as DVW all read-only objects were skipped and thus were missing in the resulting DVW workspace
- AUTOSAR export of NvRamAllocation was wrong when using AUTOSAR 2.1 format
- The AUTOSAR import didn't correctly update existing ModeDeclarationGroupPrototypes
- The minimal graphic canvas size couldn't be set using the specific dialog
- Missing GUI update after modification of NvM blocks corrected
- The description attribute of enumerators wasn't imported from the AUTOSAR XML
- In some cases the message output of external generators was truncated in the log window display
- Wrong command line parameter usage while starting external generators if a path parameter ends with a backslash
- Truncated display of constant names in record type combo-box fixed
- When using a constant to initialize a SWC local Calibration Parameter the according constant definition didn't appear within the exported AUTOSAR XML
- The check messages tab content was not cleared on closing the workspace
- Workspace was set to modified during ECU-C synchronization even if no modifications have been made
- Limitation in number of tabs in the software design window has been increased from 32 to 100
- Endlessly reappearing warning box when adding a calibration parameter with a name that already exists in the calibration parameter list fixed
- ECU-C difference dialog has displayed boolean values as 0/-1 instead of false/true
- Update of Task Mapping View was missing when a new runnable trigger with a so far unused cycle time was added
DaVinci Tool Suite Version 2.3 (SP7)
DaVinci Difference Analyzer
- Display of semantical differences between AUTOSAR XML files
- Supports System Description Files, SWC Description Files and ECU-C Files
- Integrated into Windows Explorer context menu for files with extension .arxml
- Integrated into DaVinci Developer: show differences before importing AUTOSAR XML files
DaVinci DCF Utility
- List the associated files of a DCF workspace
- Show the differences between two DCF workspaces
- Find missing files in DCF workspace
- View the content of DCB files
Usability enhancements
- Task mapping: improved trigger view
- Task Mapping: new view "Component View" to show the runnables per component
- Service Mapping: new views "Service Component View" and "Application Component View"
Tool features
- Design support for automatic creation of service ports and server runnables
- Automatic synchronization of ECU-C file when opening and closing an external configurator
- Detailed report of changed ECU-C settings during synchronization of ECU-C file
- Unified display of consistency errors and RTE generation errors
- Definition of scalings for enumeration types
- Definition semantical limits for data element prototypes
- Configuration of "switch only" and "ack only" access of mode P-ports
Fixed issues
- Wrong painting of property pages in runnable editor after resize
- Missing error message in case of invalid constants of complex data types
- Inter-Runnable-Variable Access-Mode was missing after ARXML import
- Misleading info message in case of missing INTERNAL-BEHAVIOR
- Sending the same signal on both FlexRay channels was falsely considered as signal Fan-Out
- Consistency check result for connected homopolar ports within service mapping was missing
- Missing reference on generic attribute table in DCF in case of adding attribute definitions without additional modifications
- System-Signal init value compatibility check reported wrong warning due to imprecise floating point calculation
- Frame-Node relations were not imported from ARXML for CAN and LIN Frames
- OS-Application property of tasks and description for ECU-Project got lost in DCF format
- Missing objects in AUTOSAR Export if started through multi-selection in Library Browser
- Problems occurred with DCF path definitions using slash '/'
- ECU-Project memory mapping view hasn't respected read-only attribute
- Incorrect update behavior of Port-Prototype dialog if a different Port-Interface was selected
- Ports are displayed overlapping when calling 'Arrange Ports | Align Packed'
- Ports were missing in port selection dialog because of filtering for non-strict compatible ports
- In the Properties views of port connectors, the source/destination data element prototypes were not sorted at all
- In the Properties views of port interfaces/prototypes, the data element prototypes were sorted in fixed descending order
- Moving a multi selection of input and output ports hasn't worked in the graphic display
- Tx-/Rx- evaluation during ECU-C Synchronization was wrong if the same signal was mapped to multiple messages received by different ECUs
- Faulty error message about incompatible data element to signal mapping in case of record data types
- During DCF loading the file name of currently processed ARXML file wasn't displayed
- Creeping performance of code generation and ECU-C Synchronization due to wrong evaluation of task mapping references fixed
- Wrong update of complex constants during ARXML import fixed if structure of the complex data type has been modified
- Wrong display of IOHWAbstraction in Service Mapping tab fixed
- COM-Error code while loading DCF workspace with parameter group generic attributes fixed
- Wrong Task-Priority value during ECU-C Synchronization on Asian Windows fixed
- Further performance enhancement during ECU-C Synchronization and Rte generation
- Missing consistency check for received Data-Elements
- AUTOSAR XML import containing a CompuMethod with Factor = 0 causes endless loop
DaVinci Tool Suite Version 2.3 (SP6)
Tool features
- Enhanced generator selection for ECU-Projects with support of RTE Generators in different versions
- Additional option whether string data types will use a terminating NULL-byte
- Support of open P-Ports
- Support of signal fan-in use case in ECU Configuration
- Enhanced auto-mapping rules for memory-mapping
- Support of AUTOSAR component type "ECU Abstraction" for desinging IoHwAbstraction
- Definition of communication specification at composition ports
- Various GUI round-ups and enhanced consistency checking
XML Import/Export
- Enhanced workflows:- Special overwrite of port prototypes incl. communication specification during import
- Component implementation merge dialog during import
- Optional export of top-level structure only
- User notification in case the ECU-C file has been modified by another tool
 
- Enumeration constants are now stored with their numeric value as defined in AUTOSAR
- Import of communication data (e.g. signals) is now case-insensitive, i.e. signal names cannot be different in character case only
- Support of explicit rx/tx relation for FlexRay PDUs
- Opaque value can now be stored with byte representation as defined in AUTOSAR specification
- Enhanced sorting of elements within exported ARXML files
- MICROSAR standard service port interfaces are now available as AUTOSAR import file: <DaVinci>\Data\ServicePortInterfaces.arxml
Fixed issues
- Signal invalid values were not displayed as physical value
- Some FlexRay cluster attributes were missing in AUTOSAR export
- Invalid values for 32 bit opaque data types couldn't be defined
- Generic attributes were missing at the Calibration Parameter when stored in DCF format
- Crash in AUTOSAR import fixed if file contains a ModeDeclarationGroup without a valid reference to an initial mode
- Error during AUTOSAR export if both export options 'Export user-defined attributes' and 'Create data types/constants for signals if required' are checked
- Crash fixed when opening large amount (>70) of Component Type editors simultaneously
- Wrong import of extended CAN identifiers fixed
- Missing DCF update added to avoid that deleted objects re-appear after DCF loading
- Wrong renaming if new name only differs in character case
- Memory leak fixed when importing large amount of data
- Application blocking of DaVinci / MICROSAR RTE fixed when working on the same workspace
DaVinci Tool Suite Version 2.3 (SP5)
Support of Mode Management
- Design of Mode Declaration Groups and Mode Port Prototypes
- Runnable trigger on Mode Entry, Mode Exit, Mode Switch Acknowledge
- Definition of Mode Disabling Dependencies for all runnable triggers
Further port and runnable trigger enhancements
- Support of data element invalidation
- Support of Data Reception Error trigger in case of Rx Timeout
Tool features
- Enhanced GUI and consistency checking for mode / trigger / port access definition
- Automatic mapping of service ports according to naming conventions
- Enhanced automatic data mapping for complex data types
- New consistency check to report inter runnable variables using string data-types
- Support for recursive connections (connection between ports of the same component) within an ECU SW-Composition.
- Selective diagnostics import depending on PDM-ID attribute
XML Import/Export
- Support of AUTOSAR schema 3.0.2 with DCF import/export
- Support of FlexRay ISO TP in AUTOSAR System-Description
- Temporary workspace is no longer required for DCF import/export
Fixed issues
- Data type was missing in DCF export if referenced by a port defined argument value
- Unable to adapt the signal data type according to the data mapping if the init value was missing
- Predefined data types were missing in initially created DCF workspace
- ARXML import of cycle time causes a value overflow if the decimal precision exceeds 15 digits
- Existing service mapping is no longer overwritten on importing an ECU-Extract
- Incompatible Factor, Offset, Unit was not reported by data-mapping compatibility check
- Closing the application is no longer possible while DCF saving is in progress
DaVinci Tool Suite Version 2.3 (SP4)
Support of RTE Memory Protection in DaVinci DEV
- Definition of OS application (trusted/untrusted)
- Assignment of tasks to OS applications
Extended consistency check
- Allow split and merge of connectors in SW design
- Tolerant data mapping of complex data types
- Flexible data mapping for string types (signal length 1 byte smaller than the string type is now allowed)
Usability enhancements
- Signal Routing in DaVinci SAR: Automatic signal routing now possible for individual signals
- Signal Routing in DaVinci SAR: A correct routing path is now skipped by automatic signal routing
- No more reset of global tool settings after installing a new DaVinci version
XML Import/Export
- Improved handling of BSWMD files during ECU-C synchronization
- Import/Export of COM-PROCESSING-PERIOD
- For LIN import the cluster protocol version is used for the slaves if their protocol is not set
Fixed issues
- Missing data mapping in DCF format
- String constant values don't support full character set of ISO-8859-1
- P-/R-port connector list views display duplicate components
- Obsolete check messages in the output window
- Update problems in structure graphics
- Memory leak while saving DCF workspace removed
- Endless loop on data-mapping of complex data-types fixed
- Scaling of signal/data-types has not been considered correctly in data-mapping compatibility check
- LIN diagnostics frames will now be automatically created in DaVinci Network Designer if they are not available
- Port-Interfaces were always updated during DCF saving even if no modifications have been made
- ECU-C file path is now adapted on workspace Save-As and is only written on ECU-C relevant modifications
- Different generation check results were occurred depending on the generation start method by popup-menu or generator-list
- Endless loop while opening a read-only Component-Type graphic fixed
DaVinci Tool Suite Version 2.3 (SP3)
Port API options
- Option "Enable Indirect API"
- Option "Enable API usage by address"
Miscellaneous
- Consistency warning in case of runnable entities with period 0 (except for init runnables)
- User-defined attributes for Task and ECU-Project
- ARXML import: Support of FlexRay frames sent by different ECUs in the same slot
- ARXML export: Support of LIN2.0 specific communication properties in ARXML 3.0
- DVImEx.exe command line utility is now able to import/export ARXML files based on DCF workspace
Fixed issues
- Copy&paste by keyboard shortcuts not supported in "Implementation" page of Component Type Editor
- Data mapping displays signal groups, which don't belong to the ECU project
- Problems in "Data Mapping" and "Service Mapping" page in case of multi-instantiated components on different hierarchy levels
- ECU-C Sync: ComTimeoutNotificationCallback for AliveTimeout generated in wrong format (AR2.1 instead of AR3.0)
- Range check during XML import fails in case of 64 bit signals
- Constant- and Signal-Dialog displays wrong values in case of 64 bit data-types/signals
- Automatic data mapping ignores child elements of composite data types
- Consistency check does not report duplicated component prototype names
- ARXML export: T2 values from dbc ignored when generating IPDUTiming
- ARXML export: typo in generated XML file in case of infinite limit of real data types
- ARXML import: problems with upper/lower case of short names during import of service components
- Frame mapped signal group information can't be stored in DCF
- ECU-C synchronization fails if BSWMD files are specified with path information
DaVinci Tool Suite Version 2.3 (SP2)
Miscellaneous
- Multiple instantiation of atomic component types on the same ECU is possible now
- Specification of RTE Compatibility mode API at the software component
- Full AUTOSAR support of Signals with Data-Type definition and initial value constant; Legacy Signal-Type support has been removed from DaVinci SAR
- Auto-Data-Mapping now support complex data-types that will be mapped on signal groups
- Enhanced performance during workspace saving if many data-types or constants exists
AUTOSAR XML Import/Export
- Support of officially released new AUTOSAR schema version 3.0 rev. 3
- It is now allowed to work with ECU-C and BSWMD files having different AUTOSAR patch-versions
- ARXML export has duplicated the sender-receiver mapping on R-Ports
- ECU-C synchronization is now only done for elements if the ECU-C does contain a corresponding module configuration
- SwComponentInstances for Calprm-ComponentPrototypes are no longer exported in ECU-C file
Fixed issues
- Under some circumstances the data-mapping compatibility check was running into an endless loop for complex data types
- Wrong ranges are displayed for 64 bit data types / signals in DaVinci SAR/DEV
- Some memory leaks during ECU-C file synchronization have been fixed
- In the ECU-Project data-mapping the Tx-Signal Groups were missing for local ECU communication
Known issues
- AUTOSAR export will fail if the two options "Export user-define attributes" and "Create data types/constants for signals if required" are enabled both. Workaround: start the export two times with only one option enabled.
DaVinci Tool Suite Version 2.3 (SP1)
Miscellaneous
- List view for non-graphical display of compositions
- Support of range enumerators in enum types
- Configurable consistency check for initial value of data element and mapped signal
XML Import/Export
- Import/Export of FlexRay PDUs in AUTOSAR 3.0 XML
Fixed issues
- DCF storage- DCF read-only error response doesn't work for port interfaces
- Saving DCF does overwrite read-only files
- Sheet names not stored in DCF
- ECU-Project local signal attributes were not stored in DCF
- Storage of unmapped Network-Signals in DCF added
 
- ARXML Import/Export- Invalid value is not being imported with ARXML 3.0.1
- Wrong import of signal unit attribute fixed
- Fixed import for runnable wait points on asynchronous server calls where the runnable doesn't access the server itself
- Import crashes if Data-Types doesn't contain min/max ranges
- Import crashes if timeout of synchronous server call point is missing
- Generic attributes were missing for Network-Signals
- More detailed error-message if the AUTOSAR schema version is not supported
- Fixed import of Network-Signal's init value if referenced constant is of type enumeration
- Missing import of signal's min/max values / value-type added if a data-type is referenced
- Some FlexRay node parameters were missing in import/export
- ECU-C file is no longer re-sorted after export because element order has to be obtained
 
- DaVinci swaps min and max values for data types with huge range
- ECU-C synchronize for Os/Com/Nvm now possible even if Rte is in sync
- Signals and Data-Type scaling calculation fixed for negative factors greater than -1.0
- Automatic data-mapping has falsely used signals from signal-groups for primitive data elements
- Crash in creation of NVM-Blocks if the name was already used by another NVM-Block
- Incorrect signal-routing in DaVinci SAR fixed if signals are defined in more than one global signal group
- Check of array data-types hasn't report an array size 0 correctly
DaVinci Tool Suite Version 2.3
XML Import/Export
- Import/Export of component descriptions, communication descriptions, and ECU-C via AUTOSAR 3.0 XML (XSD rev. 0001 and rev. 0002)
- Preliminary FlexRay PDU support: conversion of PDUs into signal groups during import of AUTOSAR 3.0 XML (FIBEX 2.0 compatibility)
Calibration parameters for components
- New page "Calibration Parameters" in component type editor
- Assignment of parameter groups via user defined attribute (enum attribute definition "PAR_GROUP_CAL" with arbitrary group names as enum values)
Calibration component types
- Definition of calibration component types (new realization type "Calibration")
- Definition of calibration port interfaces and calibration port prototypes
- Referencing and connecting of calibration components within a composition type
Per-instance memory
- Definition of per-instance memory of a component type
- New page "Memory Mapping" in ECU project editor to map per-instance memory to NV memory blocks (DEV only)
- Manual and automatic definition of NV memory blocks (DEV only)
- Export and synchronization of NvM section in ECU-C file (DEV only; not available in AUTOSAR 3.0 XML)
- BSWMD file for NvM module configurable for an ECU project (DEV only)
MICROSAR RTE Configurator
- New exe in bin folder: DVRteConfig.exe
- Configures the MICROSAR RTE (Task Mapping, Memory Mapping, Generation Parameters)
- Operates directly on AUTOSAR XML (ECU Extract of System Description plus associated ECU-C)
- Same RTE configuration functionality as DaVinci DEV. Not required, if DaVinci DEV is used.
DaVinci Configuration Files (DCF)
- DCF: Alternative storage format for DaVinci workspaces
- Support for file-based configuration management of DaVinci design data
- New user manual: UserManual_Working_with_DCF.pdf
Miscellaneous
- Support of asynchronous C/S communication
- Support of string data types (data types larger than 8 bytes)
- Support of explicit gateway routing in DaVinci SAR: data mapping of connected data elements to different signals supported
- Import of user-defined attributes via DaVinci attribute XML format
- Selection of both FlexRay channels (redundant transmission) possible in the "Signal Routing" page of DaVinci SAR
- Performance enhancement of Data-Mapping editor in DaVinci SAR
Fixed issues
- Missing update of VFB Tracing page after calling ECU-C synchronization
- In rare cases RTE generation can't be initiated due to model inconsistencies even if ECU project check succeeds
- Usage of atomic component type as top-level component of a Vehicle-Project is now checked and reported
DaVinci Tool Suite Version 2.2 (SP4)
Usability enhancements in graphical editors
- Display of mapping info in Function Design page of Vehicle Project Editor (SAR only)
- Automatic creation of delegation ports
- Change of port prototype alignment by Drag&Drop
- Automatic arrangement of port prototypes: alphabetically, connected/unconnected
- Copy&paste of port prototypes
- Re-connecting of connector prototypes (change the start or end port)
- Better visibility of selected objects in graphical editors
- Zooming with <Ctrl> + mouse wheel or with +/- keys
- Object positioning with arrow keys
Miscellaneous usability enhancements
- List view in ECU mapping page (SAR only)
- Display of additional context info in ECU Pin Mapping (SAR only)
- Wildcards supported in Object Selection Dialog
- Display of connectors in Object Usage Dialog
Editable network topology graphics (SAR only)
- Manual layout mode and automatic layout mode selectable
- Manual placing of ECUs and networks
- Drawing of networks via line segments
Automatic data mapping
- Automatic selection of signals for unmapped data elements
- Selection based on best guess name matching
- Adaptation of automatically created data mappings possible
Miscellaneous
- Connector Tracing Dialog for function design (SAR only)
- Extended consistency check (open ports, unmapped components, incompatibility in case of queued/unqueued data elements)
- Support of XML schema of AUTOSAR Release 2.1.4 (XSD rev. 0018)
- Update of AUTOSAR Release 2.0 XML schema export: service mapping, scaled data types with shared base types
- Relative paths of BSWMD files supported (DEV only)
- XML export for AUTOSAR Release 1.0 DTD not supported any more
Fixed issues
- Error message when trying to open properties dialog of a C/S connector
- Crash when importing a "double" data type
- Wrong check message about multiple runnable triggers
- AUTOSAR XML Import/Export of C/S communication specification was not supported
- Consistency check for enum constant values was missing
DaVinci Tool Suite Version 2.2 (SP3)
RTE features
- Support of complex hierarchical data types like arrays-of-records
- Convenient configuration of VFB tracing by import of trace functions from Rte_Hook.h
XML Import/Export
- Support of short names with 128 characters (tool option)
Enhanced consistency checks
- Detailed consistency check and data re-synchronization now available in DaVinci SAR
- Messages page in output window now available in DaVinci SAR
- Consistency check for individual component types supported
Usability enhancement
- Automatic creation of delegation ports to support bottom-up design
- Smart template generator with update functionality now available in the attached file list of a component
- Definition of a global output path in DaVinci DEV
Miscellaneous
- AUTOSAR 1.0 XML format not supported any more
Fixed issues
- Import of TargetLink-generated XML files fails in some situations
- Crash in case of incomplete imported data (missing data type reference of data element prototype)
- Default values of Generation Parameters page do not appear correctly in ECU Configuration File
- Duplicate DATA-SEND-COMPLETED-EVENTs in XML export in some situations
Known issues
- Old tool versions until V2.2.44 (SP2) crash without error message when trying to open a workspace, which has been created with V2.2 SP3
- Task mapping of service components cannot be imported from ECU Configuration File
DaVinci Tool Suite Version 2.2 (SP2)
Support of AUTOSAR release 2.1
- XML Import/Export according to AUTOSAR 2.1 schema
- Adaptation of object properties according to AUTOSAR 2.1
- RTE generation according to AUTOSAR 2.1
Service mapping
Support of AUTOSAR 2.1 concept of service components and service connectors in DaVinci DEV
- List view in Component Type Editor for non-graphical defining of service ports
- Definition and import of service Component Types
- New page "Service Mapping" in ECU Project Editor to create service connectors
RTE features
- Generation of RTE memory usage report
- Adaptation of object properties according to AUTOSAR 2.1
- Support of activation offset for cyclic runnable entities
- Support of AUTOSAR compiler abstraction and memory abstraction mechanism
- Support of AUTOSAR makefile mechanism for the RTE
- Additional APIs supported: Rte_InitMemory, Rte_IWriteRef
- Smart template generator: Update of component implementation files after changing component description
- Summary of generated files displayed in output window
XML Import/Export
- Export of scalings into separate package
- Export of various additional tags to support Elektrobit Tresos
- Additional consistency checks during import
Miscellaneous
- Demo workspace "InteriorLight" extended by a ComManager service component
- Reload workspace functionality moved from view menu to file menu with (Ctrl+F5) shortcut
Fixed issues
- Rte_Feedback returns illegal error codes in some conditions
- Generation of multiple internal S/R buffers (unqueued communication) with identical name
- Rounding problems with 64 bit signals
- Multiple buffers generated for buffered Interrunnable Variables
- DaVinci SAR: Derivation of software architecture fails if function net contains empty connectors
DaVinci Tool Suite Version 2.2 (SP1)
RTE features
- Support of Port Defined Arguments (XML import and RTE generation)
Fixed issues
- Import of enumerator names with more than 32 characters not possible
- Data Mapping on FlexRay: Same signal displayed several times in selection dialog
- Application errors of C/S port interfaces not considered in consistency check
- Record constants missing in contract phase header
DaVinci Tool Suite Version 2.2
DaVinci DEV as standalone tool
- Full-featured design of application components possible with DaVinci DEV
- Setup of ECU projects without vehicle project possible
- Signal import via DBC, FIBEX or LDF files
- Separate command line generation tool for RTE generation: DVRTEGen.exe
- Detailed consistency check of ECU projects (Messages page in output window)
AUTOSAR compliant ECU configuration with DaVinci DEV
- Storage of RTE configuration as AUTOSAR ECU Configuration File
- Synchronization of DaVinci workspace with a given ECU Configuration file possible
- Configurable list of external configuration tools for cooperative editing of the ECU Configuration File
- Obsolete concept of DaVinci Target Packages eliminated. Automatic building of CANoe target DLLs suspended.
RTE features
- Support of array types and enumeration types
- Support of exclusive areas and inter-runnable variables
- Definition of data-send-completed trigger
- State request API for data send points
- Detailed configuration of VFB tracing
- Support of symbol attribute of runnable entities
XML Import/Export
- Merge functionality during XML import to support iterative development processes
- Support of XML schema of AUTOSAR Release 2.0 SP3
Fixed issues
- Task mapping in ECU Configuration file should base on RTE event references instead of runnable entity references
- Definition of communication specifications should be only possible at assembly port prototypes
- Derived port prototypes are not incrementally updated when changing the function network
- Some element issues in XML export (missing data type at operation arguments, wrong number format)
- Inconsistent event configuration when server and all client runnables are mapped to same task
- Missing read-modify-write protection for queue overflow flags
DaVinci Tool Suite Version 2.1 PRE (SP3)
Software Design
- Software design editor for ECU software architecture
- Redefinition of the top-level granularity of the ECU's software architecture
 see 'DaVinci_DEV_ECU_SW_Design.pdf' in DaVinci Documentation Browser for detailed description
- Support of user-defined ECU-Project local ComponentPrototypes
 see 'DaVinci_DEV_ECU_SW_Design.pdf' in DaVinci Documentation Browser for detailed description
- Definition of 'Not Valid Value' and 'Initial Value' (physical) at the signal added.
- Definition of 'Invalid Value' at the DataType added. The specification of an 'Invalid Value' creates a DataType with semantic
- Definition of a receive timeout value at the input function port added.
XML Import/Export
- Import/Export of INVALID_VALUE definition according to AUTOSAR 2.0 schema
Fixed issues
- Editors remain open after deletion of corresponding context item.
- Inconsistent display of data mapping connectivity information.
- Internal connections between multi-instantiated SWCs are not correctly detected in DaVinci DEV.
- Function Design editor view is not updated when adding a new function.
- Incorrect conversion of component graphic block.
- Incorrect alignment of Function-Net derived composition types.
DaVinci Tool Suite Version 2.1 PRE (SP2)
XML Export
- Additional export of user-defined attributes in a separate AUTOSAR XML file
 see 'TechnicalReference_UserDefinedAttributeExport.pdf' in DaVinci Documentation Browser
DaVinci Tool Suite Version 2.1 PRE (SP1)
Software Design
- Refinement of existing software architecture within DaVinci DEV
- Editable runnables and generic attributes in derived software architecture
Client/Server communication
- Support of serialized C/S communication with support of AUTOSAR attribute "Can be invoked concurrently"
- Trigger sorted view for operation invokation trigger in task mapping editor
- Derivation of operation invocation trigger from function trigger specification
ECU Configuration XML export (only DaVinci Developer)
- Export of RTE requirements to Com configuration (ComNotifications)
- Export of RTE requirements to Os configuration completed (OsAlarms, OsEvents)
- Configurable definitions for Com module and Os module in generated XML file
Fixed issues
- Crash when opening runnables properties dialog in task mapping editor
- Bad performance in large function net designs
- Wrong update of derived software architecture if function ports have been changed
- Automatic signal routing was not available for complex data types with signal groups
DaVinci Tool Suite Version 2.1 PRE
Client/Server communication
- Definition of C/S Port Interfaces and C/S Port Prototypes
- Selection of Operation Invoked trigger
XML Import
- Import of XML files according to AUTOSAR 2.0 schema
- Multi-file import context supported
- Workspace consistency guaranteed by pre-import check of XML files
Enhanced usability of graphical editors
- Component Type Editor for direct editing of component types without vehicle project
- Port alignment may be defined individually for each component prototype
- Direct editing of port prototypes within the structure view
- Function Editor for direct editing of functions without vehicle project
AUTOSAR 2.0 compatibility
- Multiple triggers per runnable entity supported
- XML export for AUTOSAR 2.0 schema available
XML Export of RTE configuration (only DaVinci Developer)
- Export of RTE configuration as AUTOSAR ECU Configuration Description file
Code Generation (only DaVinci Developer)
- Separate generation step for AUTOSAR RTE
- RTE generation possible without installation of a DaVinci Target Package
Fixed issues
- Navigation between sheets via cross reference symbols not possible
- Mapping view table not displayed any more in some situations
- Constants not considered in compatibility check of record data types
- Misc. issues in XML export (wrong TREFs, empty CONSTANTS tag)
- Port prototypes of a component type not displayed in Object Usage Dialog
- Connectivity status not correctly updated in GUI
DaVinci Tool Suite Version 2.0 PRE (SP3)
Graphical Topology Editor
- Network topology can be graphically displayed in the context of a vehicle project. The graphic is calculated on demand and can't be modified. The topology objects can be selected in the graphic and edited through the objects dialogs
Modeling of devices
- Devices with electrical properties can be globally defined in the Library-Browser and assigned to pins of an ECU.
- Device Accessors within a Function Net can be mapped to concrete devices connected to the ECU pins.
- The ECU Pin Topology is graphically displayed in the ECU Topology Editor accessible through the ECU in the Vehicle Project.
Support for complex data types
- Data types can be defined as record containing any number of non-record data types as record-elements
- Data mapping is done through signal groups where each record-element has to be mapped to a compatible signal within the signal group
Support for simple data semantics
- Simple data semantics consisting of scaling information (factor, offset, unit) can be specified at integer and real data types. This information is exported as PRIMITIVE-TYPE-WITH-SEMANTICS in the AUTOSAR XML Export
- Scaling is relevant for data mapping, i.e. a scaled data type requires a scaled signal to be compatible
Support for Waitpoints
- Additional "Data Access" tab page in the component type dialog to specify the access mode for Queued (Polling, Waiting) and Non-Queued (Direct, Buffered) communication
AUTOSAR Code-Generation (only DaVinci Developer)
- Basic Software Modules updated to AUTOSAR 2.0 API specification. Existent software component code based on previous AUTOSAR specification has to be adapted to new API.
- Support of V850 Real-Target with GreenHills 4.0.7
- Support of M32C Real-Target with IAR 3.10
Fixed issues
- Data-mapping calculates wrong bit-length for some data type ranges
- Deletion of component prototypes referencing multiple instantiated component types may corrupt task mapping
- Completion of Device Accessors within Function Net was sometimes wrong
- MATLAB/Simulink support of signal groups was not working correctly
- MATLAB/Simulink import does not attach the behavior model to the function
DaVinci Tool Suite Version 2.0 PRE (SP2)
AUTOSAR Code-Generation (only DaVinci Developer)
- Support of V850 Real-Target with GreenHills 3.51
Support for direct / buffered communication
- The access mode to the data element prototypes can be specified for each runnable entity.- None: The runnable doesn't access a specific data element prototype.
- Direct: The runnable explicitly accesses a specific data element prototype. The RTE generation uses direct API calls without additional buffering.
- Buffered: The runnable implicitly accesses a specific data element prototype. The RTE generation will use additional buffering to keep the state unchanged during runnable execution.
 
Performance enhancements
- Management of workspaces with huge amount of signals has been improved
- Faster display of tree objects in Project-Explorer and Library-Browser
Configuration management suspended
- Due to some internal restructuring issues the configuration management support has been temporarily disabled. It will be re-activated in one of next releases.
Fixed issues
- Various AUTOSR XML Export issues fixed- ENTRY-POINT is now generated for the IMPLEMENTATION
- Ambiguous NUMERIC-CONSTANT if the same Data-Type is used in different ports at the Component-Type
- Description for constants were missing
 
- Copy/Paste of Network within the same Vehicle-Project may crash
- Update of Signal-Routing was incorrect under some circumstances, e.g. deleting a Network
- Data-Type ranges for real-single and real-double corrected if -INF or +INF are used
- Data-mapping creates signals with wrong bit-length
DaVinci Tool Suite Version 2.0 PRE (SP1)
AUTOSAR Code-Generation (only DaVinci Developer)
- Integration of Vector AUTOSAR Evaluation Bundle with Code-Generation of AUTOSAR SW-Architecture for PC- and Real-Target
- Support of CANoe PC-Target with Microsoft Visual C++ 6.0 / 7.1
- Support of M32C Real-Target with Renesas 5.20
Task-Mapping extension for runnables
- Each runnable entity defined at the Component can now be mapped to a task
- Additional external tasks can be defined through attachment of OIL-Component files at the ECU-Project
Documentation
- Documentation of AUTOSAR XML Export: See "DaVinci AUTOSAR XML Cross Reference" in the Documentation Browser
- User manual of Tool concepts, AUTOSAR RTE and code-generation: See "Vector AUTOSAR Evaluation Bundle" in the Documentation Browser
- Online-Help for DaVinci Network Designer CAN is now available
- Online-Help for DaVinci System Architect and DaVinci Developer is currently not available
AUTOSAR XML Export
- Option in export dialog to generate full-qualified short names
- Export of IMPLEMENTATION with ENTRY-POINT
Fixed issues
- Various AUTOSR XML Export issues fixed- Wrong format of P-PORT-PROTOTYPE-REF and R-PORT-PROTOTYPE-REF
- Short name of TIMING-EVENT missing
- Definition of BOOLEAN-CONSTANT with BOOLEAN-TYPE-TREF corrected
- Deleted signals may cause artifacts in the element <SYSTEM-SIGNAL>
- In some cases a DATA-RECEIVE-POINT was exported where a DATA-SEND-POINT was expected 
- A reference to a DataElementPrototype lacks the ComponentType; a reference to a RunnableEntity lacks the InternalBehavior
- The values created for the tags CYCLE-TIME, CYCLE-TIME-REPEAT, STARTING-TIME, and DEBOUNCE-TIME are not correctly scaled to unit second
- Sensor/Actuator creates an internal behavior using an ATOMIC-SOFTWARE-COMPONENT-TYPE-REF instead of a SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE-REF
- Constants defined in the scope of a Data-Type were not exported
- Object references using a * for fully dereferencing of the current context are valid definitions according to the "Template Formalization Guide", but may be difficult to interpret for XML-Importer. The creation of references with stereotype <<instanceRef>
- > have been changed by adding the name of a Port-Prototype in front of the qualified name: "port_prototype_short_name*/Element1" 
 
- Component-Prototype can only be created within Compositions. Trying to create it within other Component-Type was not inhibited and causes a crash.
- ECU specific signal choice dialog causes crash in data mapping
- Object can't be renamed to a name with different character case
- Wrong behavior of radio-buttons within Data-Type dialog
- Autorouting of signals doesn't recognize ambiguous receiver within one network correctly
- Mapping of runnables causes deletion of network signals
- Drag&Drop for Sensor/Actuator in mapping page was missing
- Runnable name and description was not stored correctly
- In some cases the function port update in function design structure graphic was missing
- Crash in interface editor if port interface of an exiting port prototype was deleted
- Wrong Tool-Tip behavior in trees consumes all mouse inputs on the subjacent item
- Deletion of a ECU-Project within the Vehicle-Configuration causes a fully deletion of the ECU-Projects itself and not of the link
DaVinci Tool Suite Version 2.0 PRE
Prerelease to introduce the new tool concept and the AUTOSAR design support. Comprised tools:
- DaVinci System Architect 2.0 PRE
- DaVinci Developer 2.0 PRE
- DaVinci Network Designer CAN 1.0 PRE
Support of Code Generation/Target Packages and ECU State Management is suspended.
New tool concept
Specialized tools for each design use case:
- DaVinci System Architect: Specialized tool for system design
- DaVinci Developer: Specialized tool for ECU code integration
- DaVinci Network Designer: Specialized tool for network design
New tool framework
- Common look-and-feel for all DaVinci tools
- Introduction of projects (vehicle project or ECU project) as "working context"
- New concept for editor windows
Function Design (only DaVinci System Architect)
- Definition of functions with signal interfaces
- Definition of device accessors for specifying signal interfaces of sensors and actuators
- Function-local specification of signal properties allowed to support preliminary integration of a function net
- Manual and automatic definition of function port connectors
- Graphical visualization of function net consistency
- Definition of hierarchical signal groups
- User-defined stereotypes for signals and functions
- Stereotypes are configurable through the STEREOTYPE.INI file located in the DaVinci Bin\Config directory
- Optional display of stereotypes within function graphic
- Function trigger definition (cyclic, spontaneous, on input signal)
- Definition of function execution sequence
- Derivation of a function net as an equivalent AUTOSAR SW architecture
AUTOSAR-compliant SW Design (only DaVinci System Architect)
- Definition of data types
- Definition of port interfaces with data element prototypes
- Graphical design of atomic software components types and composition types
- Definition of runnable entities
- Trigger types "periodically" and "data reception" supported
- Graphical design of SW structure by definition of component prototypes
Data Mapping (only DaVinci System Architect)
- Mapping of network signals to data elements
- Analysis of data element connectivity (internal vs. external communication)
ECU Mapping (only DaVinci System Architect)
- Mapping of functions or components to ECUs
- Definition of mapping constraints to ensure that all sub-functions/sub-components are located on the same ECU
Signal routing (only DaVinci System Architect)
- Definition of signal routing paths within the vehicle topology
- Signal routing across gateway ECUs supported
Export of AUTOSAR XML-files (only DaVinci System Architect)
Export of design data into the AUTOSAR XML-format (AUTOSAR 1.0, DTD revision 12342).
- Export of complete vehicle projects with all sub-objects
- Export of individual objects like data types, port interfaces or component types
User-defined stereotypes (only DaVinci System Architect)
- Stereotypes are configurable by a STEREOTYPE.INI file located in the DaVinci Bin\Config directory
- Stereotypes supported for functions, signals and signal groups
Import/Export of MATLAB/Simulink models (only DaVinci System Architect)
- Import of Simulink models as function hierachy
- Export of individual functions or complete function hierarchies as Simulink model
- Import/Export includes signal groups and stereotype annotation
- An example model "ImportExample.mdl" is available in the "Work"-Directory of the DaVinci installation
- An example workspace "ImportExample.dvw" having imported "ImportExample.mdl" is available in the "Data"-Directory
- Style guide for Simulink import is available in the DaVinci documentation browser
Network design (only DaVinci Network Designer)
- Explicit definition of CAN messages and network signals
- Definition of Tx- and Rx-relations
- Definition of message layout with various display schemes
- Manual or automatic definition of DLC
- Display of gateway tables
- Network timing analysis
- Import/Export of DBC
- Import of MDC files
Task mapping (only DaVinci Developer)
- View modes for displaying the components in a flat list or sorted by trigger types
Object Usage Dialog (only DaVinci System Architect and DaVinci Developer)
- Tracking of usage relations between objects in the workspace
- Two tracking directions:- Referencing objects: Upward tracking (which objects use me)
- Referenced objects: Downward tracking (which objects do I use)
 
Search Function (only DaVinci System Architect and DaVinci Developer)
- Searching of objects by name
- Search for specific object types
Limitations
- Auto-mapper for network signals not available
- Multi-instantiation only supported for atomic software component types, not for composition types
- All runnable entities of a component are always mapped to the same task
DaVinci Tool Suite Version 1.0 (SP4)
Support of Microsoft Visual C++ 7.1
- PC-Target generation using CANoe OSEK library is now available for Visual C++ 7.1 compiler, which is part of Microsoft .NET 2003 release. Legacy Visual C++ 6.0 is still supported.
CANdesc Basic Diagnostics for DB-Kom
- Support for CANdesc Basic diagnostics using DBKOMgen Version 2.51
- Extension of initial firmware generation for application callbacks
- Attachment of generated diagnostic files
- Notes concerning the generated template file "AppDesc.c":
 An application diagnostic template file "AppDesc.c" will be generated in the ECU output directory at each code generation. This file has to be initially attached once at the ECU to fulfill the diagnostic functions. It is highly recommended to use an ECU specific name rather than the standard "AppDesc.c". After attachment the file may be modified to code application specific diagnostic functionality.
Event Triggered Execution
- In addition to the cyclic execution of software components, it is now possible to defined events to tigger execution of procedures at the behavior components.
- There may be multiple procedures with multiple trigger conditions defined at each behavior component.
- The DaVinci ECU-Callback object is superseded by the trigger concept and thus no longer available
- Possible triggers are: State changes, Timer, Signals
- The Simulink/TargetLink blocksets are enhanced by a procedure block
Task-Mapping
- Task-Mapping for software components is now defined in the mapping view of the Hardware & Mapping Editor
- See topic "Task mapping of software components" within the DaVinci online help for detailed information
Iterative OSEK Configuration
- Changes in the OSEK configuration made in the OIL-Configurator are now read back and stored into the DaVinci workspace.
- Storage is done for each ECU separately and can be modified through the OIL-Configurator without losing previous modifications
- Additional OIL-Files can be attached at the ECU or software component
TargetLink 2.0
- Implementation of behavior components can now be done with TargetLink 2.0 using MATLAB R13.
- An upgrade mechanism of DaVinci models from TargetLink 1.3 to 2.0 is supported
- A data dictionary is used for each behavior component with additional pool definitions for DaVinci
- The single XML-Files for pool definitions can be found in <DaVinci>\Generation\Behavior\Matlab\R13\TL20\config
- The previous implementation of TargetLink 1.3 using MATLAB R12 is still available.
Fixed issues
- Attached files are now stored with paths relatively to the working folder
- Linker problem with multiple RTW generated Stateflow files at the same ECU
- Under rare circumstances modifications at attached files may be lost if working on the same behavior component with both DaVinci tools in parallel
- Unhandled exception if output dir can't be created during code generation
- Wrong ESM procedure execution during startup of CANoe simulation
- Usage of ESM on ECUs without mapped software component leads in code generation errors
DaVinci Tool Suite Version 1.0 (SP3)
Parallel working with both DaVinci tools on the same workspace
- Convenient switching between the tools without closing the workspace
- Parallel editing of the objects without mutual blocking of the tools
Enhanced Target Package architecture and selection
- Selection of used Target Package at each ECU and Mapping-System
- Parallel installation of Target Packages in different versions supported
DaVinci Documentation Browser
- New convenience tool to display documents and help files of DaVinci tools and Target Packages
MATLAB/Simulink Import
- Recursive import of a Simulink subsystem as DaVinci software component structure
Internal Perl usage
- External Perl installation no longer required
- DaVinci installs Perl (build from CPAN sources Version 5.8.0) locally into the DaVinci generation directory
- Any other Perl installations may exists on the PC and will not affect DaVinci code generation
DBC file export
- Export of a mapping systems as dbc files
DBC Import
- Support of sub-signals
- Renaming of attached DBC-Files
- Some minor roundup features and fixed issues- Enhanced check of DBC import conflicts
- Check on imported DBC message ID while creating DaVinci messages
- No more inconsistencies when deleting a DBC-imported signal from a bus interface
- Correct update of properties on DBC-imported signals
- Interpretation of some signal attributes corrected: start bit, init value, timeout
 
Configuration Management
- Permanently disconnecting a workspace from a configuration management repository
Fixed issues
- Generation rebuild fails without warning if output files are locked by another application
- Attachment of large files via network was extremely slow
- Compiler parameter settings are not stored after closing/reopen workspace
- Opening a .dvw file through Windows Explorer doesn't work under some circumstances
DaVinci Tool Suite Version 1.0 (SP2)
Rework of target package settings
Please check and adapt your settings within the Mapping-Systems
- Communication system type is now specified the Bus and no longer at each ECU
- New generation parameter dialog at the Mapping-System and their ECUs available
- CANoe firmware generation is now specifiable at each ECU within the Mapping-System
New DBkom version 2.48
- Please adapt all workspaces using older DBKom versions at the ECU and Mapping-System
CAN Multi-Channel support
- Support for more than one CAN-Channel at an ECU with DBKom communication system
Software System Sheets
- Graphical grouping of components on several sheets
- Cross reference links to follow signal paths across sheets
MATLAB/Simulink Export
- Export of a Software System as one MATLAB/Simulink model containing all models attached to the used software components
MATLAB/Simulink/TargetLink functional interface
Please re-generate your existent, attached models with the enhanced blockset
- Enhanced signal blockset with additional parameter
- Additional blockset for ECU State Manager and Network Management
XML Import/Export
- Software Component exchanged (incl. attached files) via XML
New CPU-Variants available
- S12DG128
- HC12DG128
Attached files enhancements
- Additional attached files at the ECU within the Mapping-System
- Support for binary file types (OBJ, LIB)
- Additional file categories to specify file action within the generation make process
Fixed issues
- Objects names within the Mapping-System are not checked correctly on uniqueness
- Online help couldn't be started through adapter dialogs
- Messages without bus signals are deleted during Mapping-System update
- Missing explorer update after importing or selecting bus signals through a bus interface
- Crash in subseqently renaming of component procedures
- Missing connections when calling 'Complete Device Accessors' function
- Wrong model name in initial TargetLink model generation
DaVinci Tool Suite Version 1.0 (SP1)
Fixed issues
- After installation on a clean PC, an immediate Simulink generation will fail due to missing path settings
- Some ECU specific parameters of the communication system can't be saved
- Wrong Signal-Prefix (dvFwSim instead of dvFw) in template generation of Initial I/O Firmware for real ECUs
- Missing update in Hardware-System explorer after creating new ECUs or Buses
- Missing bus signals in Mapping-System after ECU exchange
- Renaming of configurations may corrupt workspace and configuration management interaction
- Component interface can't be removed in interface view under some circumstances
- The same Signal in different versions can be used within one component. This is inconsistent and must not be allowed.
- General error during code generation if the Mapping-System is read-only (i.e. checked in)
- Renaming of generic attributes is not possible
- Copy & Paste of diagnostic settings for an ECU is missing
- ECUs without bus-signals won't be generated correctly
- Missing check on unique sensor/actuator names
- Wrong Network Management ID generation in DBC file
DaVinci Tool Suite Version 1.0
Extra installation of ActivePerl required
It is required to install ActivePerl Version 5.6.1 build 631 or higher in a separate step. ActivePerl may be downloaded from ActiveState at http://www.activestate.com/Products/ActivePerl/
Workspace conversion
A conversion of older workspaces with DTD 1.x to DTD 2.0 has to be performed for loading with DaVinci 1.0. There are two possibilities to perform this step:
- Implicitly: Loading a workspace will automatically display a dialog for
conversion.
 Please read the notes in this dialog carefully
- Explicitly: Use the DVCvt.exe console application to convert a workspace with
parameter -d2.0
 The parameter -f is always active for conversions to DTD 2.0, i.e. the workspace will always be saved in the new version
New Interaction Layer Versions
Please adapt all workspaces using older target settings at the ECU and Mapping-System:
- DBKom 2.46
- GM-LAN 3.99
- Vector-IL 3.99
Configuration Management
- Integration of Microsoft Visual SourceSafe
Diagnostic Support
- Integration of CANdela and CANdesc for GM-LAN
- Automatic creation of diagnostic stubs
ECU State Manager
- Design of ECU State Machines
- Definition of procedures with conditional execution
MATLAB/Simulink import
- Import of a Simulink subsystem as DaVinci software component
Support of ECUs with predefined communication (DBC-Import)
- Import of messages and signal mapping when using the auto-mapper for bus signals
Support for PowerPC Target
- Target Package for MPC555 with DBKom 2.46 available
Signal states
- Specification of signal error conditions at design time
- Extensions of DaVinci Target API for accessing the signal state
DaVinci Tool Suite Version 0.9.8
Changes in the Target API
- Please replace the following function calls in the behavior code of the C-coded
components:- "dvSetSignalRequest()" by "dvRequestSignal(DV_SIGREG_ALL)"
- "dvClearSignalRequest()" by "dvReleaseSignal(DV_SIGREG_ALL)"
- "dvSignalsAvailable()" by individual calls of "dvGetState<SignalName>()"
 
- Interface to CAN-Transceiver handling changed for systems using CCL (e.g.
GM-LAN)
 see CodeGenerationManual.pdf and exemplary attached file HC12_Transceiver.c at the ECUs
SoftwareSystem Table Editor
- Tabular viewing and editing of SoftwareSystems without graphic
Display of realization type in component graphic
- Components will now have a visual distinction if they are included, structure or behavior components
Target Selection of attached files
- Firmware and component files get a new attribute to specify, if they are used in PC- and/or Real-Target
Support for Logical Networks (LN)
- Support for Logical Networks (LN)- LN Definition in Software-System
- Integration with GM-LAN 3.97.00 Virtual Networks
- Import of SAAB 3FD Models into DaVinci with LN
 
Performance Enhancements
- Opening Component Mapping
Fixed issues
- Unmapped signals won't be displayed within Mapping-System check
- Wrong display of open signal paths
- No Mapping-System check after assigning a signal to a sensor
- No status information text output for a missing Software- or Hardware-System
DaVinci Tool Suite Version 0.9.7 (SP1)
Fixed issues
- Linker error with multiple Simulink R13 models in one ECU
- Check-State of mapping system not displayed correctly
- Assertion, when activating a Mapping-System with attached DBC-File
DaVinci Tool Suite Version 0.9.7
GM-LAN Integration
- Support of GM-LAN for Canoe and HC12 Target without Virtual Networks
Workspace DTD Converter Tool (DVCvt.exe)
- Conversion of workspaces to a newer data model version
Sorting of Trees
- All Explorer Trees (Global, Favorites, Categories) are now sorted
Name length limitation of 32 characters
- All object names are now limited to a length of 32 characters to ensure proper usage in code generation and DBC-Files
Workspace Path checking
- Workspace naming and path length will now be checked to ensure a maximum path length of 260 characters
Performance Enhancements
- Loading Signals and Components
- Editing Signal Types
Fixed issues
- Disconnecting an ECU from a Bus causes an error
- In some situations, renaming of objects was impossible
- "New Workspace" command doesn't work in Hardware&Mapping Editor
- Creating a new object category with an existing name will crash
DaVinci Tool Suite Version 0.9.6 (SP1)
Support for MATLAB R13
- Adaptation of code generation for MATLAB R13 using RTW-GRT
DaVinci Tool Suite Version 0.9.6
Support of Large Systems
- Rework of object loading and tree display
- Enhancements in graphic display
- Smart update mechanisms in tools (Trees, Object-Viewer and Graphic)
- Rework of Mapping-System data update mechanisms
Object Categories
- User defined grouping of objects with categories
- Favorite Lists
Enhanced checking of attached files
- Hints on closing, saving and generating if attached files are not up-to-date
XML Import Tool (DVImEx.exe)
- Import of SAAB 3FD Models into DaVinci
Usability
- Stop-Button for Code Generation added
- Generate-All command added
- Save-Button won't be grayed if workspace is not modified
Perl Installation Check
- New script DVPerlCheck.pl to retrieve information about current Perl installation
Fixed issues
- Missing update on DBC-Signal import
- Mapping system consistency: Sensor signal specified as actuator is not detected as error
- Overlapping display of interface names
- Property windows of a message causes a crash
- Multiple Tx-nodes of Tx-messages crashes in DB-Kom
- Deleting a SWS corrupts the Mapping-System
Additional Information
Vector Informatik GmbH Support
- Our business hours are Monday to Friday from 9:00 am to 5:00 pm (CET) - Phone: +49.711.80670.200 
 Fax: +49.711.80670.111
 E-Mail: support@vector.com
 Online Report Form: http://vector.com/support
3.33 -
W3C SOFTWARE NOTICE AND LICENSE
http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications:
- 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.
 
Last revised $Id: copyright-software-20021231.html,v 1.11 2004/07/06 16:02:49 slesch Exp $
4.1 - TL113A_MfgSrvSuprt Peer Review Checklist
Overview
Summary SheetSynergy Project
Sheet 1: Summary Sheet

Sheet 2: Synergy Project
5.1 - PAGe_ReleaseNotes
5.3 - PAGe_ReleaseNotess

Release Notes PAGe
Project
adaptive BMW AUTOSAR Core Rel. 1
Author
BMW AG
Release Date
2017-11-09
Version
1.1.0
Status
Release
Hotline
+49 89 382 - 22522
Contact
abac@bmw.de
https://asc.bmw.com/jira/browse/BSUP (extern)
https://asc.bmwgroup.net/jira/browse/BSUP (intern)
Revision History
Version
Date
Issues
1.1.0
2017-11-09
BAC-6409, BAC-6509, BAC-6150
1.0.0
2017-06-29
Company
Bayerische
Motoren Werke
Aktiengesellschaft
Postal address
BMW AG
80788 München
Office address
Forschungs- und
Innovationszentrum
(FIZ)
Hufelandstr. 1
80937 München
Telephone
Switchboard
+49 89 382-0
Internet
www.bmwgroup.com
ReleaseNotes_PAGe, Version 1.1.0, Software Platforms
Page 1 of 3

1
Module Description
Tool to generate text from AUTOSAR paramconf.
2
Revisions and Modifications
Revision 1.1.0 [Released]
Item
Description
CR ID:
BAC-6409
CR Headline:
PAGe should only rely on Python std library modules.
Description of Issues:
The dependecy of lxml shall be removed
Description of Changes:
The parsing of the XML was changed so PAGe now builds an
internal model and does not rely on xpath expressions.
Changed Files:
utility/utility.py
utility/exceptions.py
core/command.py
codeparts/codepart.py
utility/xpath_resolver.py
core/model.py
core/xmlcache.py
core/verify.py
Compatibility:
Item
Description
CR ID:
BAC-6509
CR Headline:
PAGe must be more robust for shortnames
Description of Issues:
Improve Robustness of Shortnamepath operations
Description of Changes:
Allow strings and trailing slashes in shortnamepaths.
Changed Files:
codeparts/inputtext.py
utility/utility.py
codeparts/inputpart.py
core/model.py
Compatibility:
Item
Description
CR ID:
BAC-6150
CR Headline:
BAC 4.3: Provide shell wrapper/.cmd-file for PAGe
Description of Issues:
Add a shell script to wrap page call
Description of Changes:
A shell script is provided in the bin directory. This allows calling
page without manually setting the PYTHONPATH.
Changed Files:
bin/page
Compatibility:
ReleaseNotes_PAGe, Version 1.1.0, Software Platforms
Page 2 of 3

Revision 1.0.0 [Released]
Item
Description
CR ID:
CR Headline:
Initial Release for SP2021
Description of Issues:
Initial Release for SP2021
Description of Changes:
Initial Release for SP2021
Changed Files:
Compatibility:
ReleaseNotes_PAGe, Version 1.1.0, Software Platforms
Page 3 of 3
Document Outline
5.4 - PAGe_Review
Overview
Summary SheetSynergy Project
help
Version History
Sheet 1: Summary Sheet
| Rev 2.01 | 21-Feb-18 | |||||||||||||||||||||||||||||
| Nexteer EA4 SWC Implementation Peer Review Summary Sheet | ||||||||||||||||||||||||||||||
| Component Short Name: | PAGe | Revision / Baseline: | TL125A_PAGe_1.1.0_0 | |||||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Work CR ID: | EA4#20630 | |||||||||||||||||||||||||||
| Modified File Types: | ||||||||||||||||||||||||||||||
| Check the file types that needed modification for the Work CR(s); macros for the check boxes will populate the appropriate checklist tabs for the review. | ||||||||||||||||||||||||||||||
| Review Checklist Summary: | ||||||||||||||||||||||||||||||
| Reviewed: | ||||||||||||||||||||||||||||||
| At start of review, all items below should be marked "No". At the end of the review, all items should be marked "Yes" or "N/A" where N/A indicates the reviewers have reviewed the existing (unchanged) item and confirmed no updates were needed for the Work CR(s). | ||||||||||||||||||||||||||||||
| N/A | MDD | N/A | Source Code | N/A | PolySpace | |||||||||||||||||||||||||
| N/A | Integration Manual | N/A | Davinci Files | |||||||||||||||||||||||||||
| All required reviewers participated | ||||||||||||||||||||||||||||||
| Comments: | This is a python script provided by BMW with the BAC releases for code generation. | |||||||||||||||||||||||||||||
| This replaces Artt for the BAC modules | ||||||||||||||||||||||||||||||
| Time spent ( to the nearest half hour) | review preparation | review meeting | review follow-up | |||||||||||||||||||||||||||
| Change owner: | 0.5 | 0.5 | 0 | |||||||||||||||||||||||||||
| Component developer reviewers: | 0 | 0 | 0 | 1 | ||||||||||||||||||||||||||
| Other reviewers: | 0 | 0 | 0 | |||||||||||||||||||||||||||
| Total hours | 0.5 | 0.5 | 0 | 1 | ||||||||||||||||||||||||||
| Content reviewed | ||||||||||||||||||||||||||||||
| Lines of code: | Elements of .arxml content: | Pages of 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 SWC Owner and/or SWC Design author and Integrator and/or SW Lead 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. Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained. Before the peer review, the change owner shall: (NOTE - time for completing these items is to be counted as the Change Owner Review Prep Time) o Review the previous component peer review and copy any relevant comments to the new review sheet. o Review all checklist items and make all corrections needed, so that the component is ready for peer review. The expectation is that peer review should find very few issues, because the change owner has already used the checklist to ensure the component changes are complete and correct. o Fill in all file name and version information as needed on peer review checklist tabs (file names may be copied from the previous peer review where appropriate) o Fill in checklist answers (Yes/No/NA pulldowns) ONLY on those items which are NA for the current change. All other checklist items should be blank going into the review meeting. During the peer review meeting: o For each page of the review, first review the items already marked as N/A for this change, to confirm that reviewers agree with this assessment; change the checklist box to blank if it is found that the item does apply. o Then review the items with the checklist box blank. After reviewing each of these items, the checklist box will be marked as "Yes", or the checklist box will be marked as "No" with needed rework indicated or with rationale indicated. o If any items are marked "No" with rationale indicated, this must be approved by a software supervisor or the software manager; there is a line in the "Review Board" section of each tab to indicate who approved the "No" items on that tab. | ||||||||||||||||||||||||||||||
 
 
 
 

Sheet 2: Synergy Project
| Rev 2.01 | 21-Feb-18 | |||||||||||||||||||||||
| Peer Review Meeting Log (Component Synergy Project Review) | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Rationale is required for all answers of No | ||||||||||||||||||||||||
| New baseline version name from Summary Sheet follows | Yes | Comments: | ||||||||||||||||||||||
| naming convention | ||||||||||||||||||||||||
| Project contains necessary subprojects | Yes | Comments: | ||||||||||||||||||||||
| Project contains the correct version of subprojects | Yes | Comments: | ||||||||||||||||||||||
| Design subproject is correct version | N/A | Comments: | Design not required for TL projects | |||||||||||||||||||||
| .gpj file in tools folder matches .gpj generated by TL109 script | N/A | Comments: | Not required for TL projects | |||||||||||||||||||||
| File/folder structure is correct per documentation in | N/A | Comments: | Not required for TL projects | |||||||||||||||||||||
| TL109A_SwcSuprt | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Review Board: | ||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Review Date : | 03/15/18 | |||||||||||||||||||||
| Lead Peer Reviewer: | Shameel | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
| Rationale/justification for items marked "No" approved by: | ||||||||||||||||||||||||
Sheet 3: help
| Summary sheet: | |||||||||||||||
| Intended Use: Identify which component is being reviewed. This should match the component short name from the DataDict.m fileand the middle part of the Synergy project name, e.g. Assi for the SF001A_Assi_Impl Synergy project | |||||||||||||||
| Intended Use: Identify the implementation baseline name intended to be used for the changed component when changes are approved E.g. SF001A_Assi_Impl_1.2.0 | |||||||||||||||
| Intended Use: Identify the developer who made the change(s) being reviewed | |||||||||||||||
| Intended Use: Identify the Implementation Work CR whose work is being reviewed (may be more than one) | |||||||||||||||
| Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. | |||||||||||||||
| Source code: | |||||||||||||||
| This item includes looking at all layers of Simulink model for possible color coding not reflected at a higher level, and includes looking at any intermediate SWC Design versions between the version being implemented and the version that was included as a subproject in the previous implementation. | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: For SWC Designs, list the Synergy baseline number (just the number part of the Synergy baseline name) of the SWC Design baseline being implemented. E.g., for SF001A_Assi_Design_1.3.1, this field would say "1.3.1" | |||||||||||||||
| Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s). | |||||||||||||||
| Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). | |||||||||||||||
| Intended Use: list version/revision of latest released Software Design and Coding Standards document. | |||||||||||||||
| Davinci Files | |||||||||||||||
| Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs | |||||||||||||||
| Polyspace | |||||||||||||||
| eg. 2013b | |||||||||||||||
| Integration manual | |||||||||||||||
| Intended Use: Identify which file is being reviewed | |||||||||||||||
| Intended Use: Identify which version of the integration manual has been reviewed. | |||||||||||||||
| Synergy | |||||||||||||||
| Refer to EA4 Common Naming Conventions document, section “Synergy Baseline Names for core components” | |||||||||||||||
| The following subprojects should be included for all component implementations: • AR200A_ArSuprt_Impl • AR201A_ArCplrSuprt_Impl • TL101A_CptRteGen • TL103A_CplrSuprt • TL109A_SwcSuprt • Corresponding _Design project used for the implementation The following subprojects should be included as needed by each component: • AR10xx_Nxtr*_Impl library components as needed by each component • AR202x_MicroCtrlrSuprt_Impl as needed (for register header files for components making direct register access)[add notes about when to add a stub header file] • Xx999x_xxxxGlbPrm_Impl as needed by each component • TL105A_Artt for components with generated content The following should NOT be included as subprojects: • TL107x_DavinciSuprt (aka StdDef) • TL100A_QACSuprt (QAC subproject was previously included but should be removed going forward) • Any other component (not mentioned anywhere above) whose .h file is needed. For these components, a “stub” .h file should be created, containing only the multiple include protection and the definitions and function prototypes actually needed by the component with the #include, and placed in the “including” component’s local\include folder. | |||||||||||||||
| misc in Summary sheet | |||||||||||||||
| (integrator, designer, unit test coordinator, etc.) | |||||||||||||||
| For a new component, use number of lines in all source files reviewed, including files in the src and include folders and any generated cfg.h and cfg.c files. For a changed component, try to add up how many lines, including comments and blank lines, were in the changed areas that were reviewed. Not just the actual changed lines, but the number of lines in the blocks of code you had to look at to review the change. | |||||||||||||||
| add up the number of ports, number of PIM variables, number if IRVs, number of runnables, number of NVM blocks in the component (all of them for review of a new component, the new and modified ones for review of a change) | |||||||||||||||
| add the number of pages in the MDD and integration manual for a new component; for a modified component, count the number of pages that contained a change. | |||||||||||||||
| Reviewer | Required attendance for this type of change | Review spreadsheet tab(s) | |||||||||||||
| Component group peer | All | All | |||||||||||||
| Component owner and/or SWC Design author | *Initial creation of any new component *Simulink model changes (any change to the model other than just updating the change log) | Source | |||||||||||||
| Integrator and/or SW lead of first program planning to use the component | *Initial creation of any new component *new or changed NVM blocks, NVM datatypes, or NVM usage (added or removed or changed NVM API calls in any runnable) *Major rev (X changed in the X.Y.X design baseline number; means there was a component interface change) *new or changed config params *all MM component changes | Davinci files, Integration manual, source for NVM changes and for all MM component changes. | |||||||||||||
| Unit test coordinator | Fixes for coverage issues | Source | |||||||||||||
| SQA | None | None | |||||||||||||
| For each reviewer category listed on each tab, there should either be • the name of the reviewer who attended or • a comment indicating o why that reviewer was not required for this change or o who approved holding the review without that required reviewer (approval must be from the software manager or a software supervisor) | |||||||||||||||
Sheet 4: Version History
| File Version History | ||||||
| Version | Description | Author(s) | Revision Date | Approved By | Approved Date | Status | 
| Draft/ Released | ||||||
| Template Version History | ||||||
| Version | Description | Author(s) | Revision Date | Approved By | Approved Date | Status | 
| 1.0 | Initial Version | SW Engineering team | 24-May-15 | NA | NA | Released | 
| 1.01 | Changed name to be EA4 specific | SW Engineering team | 25-Jun-15 | NA | NA | Released | 
| 1.02 | Modified Summary Sheet General Guidelines, Clarified wording on first item in Synergy project sheet. | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.02 | Made corrections and clarifications to Source Code check list. | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.02 | updated Davinci, MDD, and Polyspace/QAC tabs | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.03 | Aligned to portal version guidelines | Umesh Sambhari | 21-Nov-17 | NA | NA | Released | 
| 2.00 | Summary sheet template: Changed title to indicate Implementation Peer Review Corrected and/or clarified mouse hover comments, added instructions, renamed some fields. Changed the default setting to "No" on the items reviewed | SW Engineering team | 29-Nov-17 | Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar | NA | Released | 
| Source code template: Removed hyperlink for naming conventions, corrected name of naming conventions document, added version field for naming conventions document. Changed item about requirements tags to reflect that they should be removed Added clarification that all combinations of conditionally compiled code must be checked Item about accurately implementing SWC Design is modified and a new item added, both to clarify where to look when determining needed changes. Added point for version of common naming conventions Reworded multiple items for clarity | SW Engineering team | 29-Nov-17 | ||||
| Synergy project template: added items for file/folder structure added point on .gpj file in tools folder | SW Engineering team | 29-Nov-17 | ||||
| Davinci files template: Clarified the StdDef item Added new item for OBSOLETE Clarified item on datadict.m comparison Removed the references to .m file helper tool Updated to reflect that all component should now use only implementation data types Added points on PIMs and NVMs | SW Engineering team | 29-Nov-17 | ||||
| All template tabs: Added/clarified/removed mouse hover comments. Updated Review Board section Removed the gridlines from all tabs Updated titles to say "Nexteer SWC Implementation Peer Review" Changed all occurences of "FDD" to "SWC Design" | SW Engineering team | 29-Nov-17 | ||||
| 2.01 | Added a help tab and appropriate links Added field on Summary sheet to report hours spent and content reviewed Changed wording in an item in Polyspace tab and Source code tab | SW Engineering team | 21-Feb-18 | Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar | 21-Feb-18 | Released | 

5.5 - PAGe_UserManual
5.6 - PAGe_UserManual_ind
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
5.7 - PAGe_UserManuals

User Guide PAGe
Project
BMW AUTOSAR Core 4 Rel. 3 and adaptive BMW AUTOSAR Core Rel. 1
Author
BMW AG
Release Date
2017-11-09
Version
1.1.0
Status
Release
Hotline
+49 89 382 - 32233 (classic) / +49 89 382 - 22522 (adaptive)
Contact
bac@bmw.de (classic) / abac@bmw.de (adaptive)
https://asc.bmw.com/jira/browse/BSUP (extern)
https://asc.bmwgroup.net/jira/browse/BSUP (intern)
Revision History
Version
Date
Changed by
Description
1.1.0
2017-11-09
JC-42
Initial Documentation Release
Company
Bayerische
Motoren Werke
Aktiengesellschaft
Postal address
BMW AG
80788 München
Office address
Forschungs- und
Innovationszentrum
(FIZ)
Hufelandstr. 1
80937 München
Telephone
Switchboard
+49 89 382-0
Internet
www.bmwgroup.com
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 1 of 22

Table of Contents
1 Overview
3
1.1
Purpose
3
1.2
Usage
3
1.2.1
Generation
3
1.2.2
Validation
3
1.2.3
verb
3
2 Acronyms and Abbreviations
4
3 Functionality
5
3.1
Command Line Usage
5
3.2
Fileformat
5
3.3
Available Function and Objects
6
3.4
Handling of paramconf
7
3.5
Notes ARXML shortcuts
7
3.6
Loops
7
4 Examples
8
4.1
Basic Navigation
8
4.1.1
ARXML Files
8
4.1.1.1
input.arxml
8
4.1.2
pgen Files
9
4.1.2.1
input.pgen
9
4.1.3
Command line
10
4.1.4
Console Output
10
4.1.5
File Output
10
4.2
Logging
11
4.2.1
pgen Files
11
4.2.1.1
input.pgen
11
4.2.2
Command line
11
4.2.3
Console Output
11
4.2.4
File Output
11
4.3
Usage of Code Blocks
11
4.3.1
pgen Files
12
4.3.1.1
input.pgen
12
4.3.2
Command line
12
4.3.3
Console Output
12
4.3.4
File Output
12
4.4
Conditionals
13
4.4.1
ARXML Files
13
4.4.1.1
input.arxml
13
4.4.2
pgen Files
14
4.4.2.1
input.pgen
14
4.4.3
Command line
14
4.4.4
Console Output
15
4.4.5
File Output
15
4.5
More Functions
15
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 2 of 22

4.5.1
ARXML Files
15
4.5.1.1
input.arxml
15
4.5.2
pgen Files
17
4.5.2.1
input.pgen
17
4.5.3
Command line
17
4.5.4
Console Output
17
4.5.5
File Output
17
4.6
ARXML Stuff
17
4.6.1
ARXML Files
18
4.6.1.1
input.arxml
18
4.6.2
pgen Files
19
4.6.2.1
input.pgen
19
4.6.3
Command line
19
4.6.4
Console Output
19
4.6.5
File Output
20
4.7
Filtering Elements
20
4.7.1
ARXML Files
20
4.7.1.1
input.arxml
20
4.7.2
pgen Files
21
4.7.2.1
input.pgen
21
4.7.3
Command line
21
4.7.4
Console Output
21
4.7.5
File Output
22
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 3 of 22

1
Overview
Purpose
This user guide describes the functionality and usage of the Python AUTOSAR Generator (PAGe).
PAGe is a generator for text templates which has some knowledge of the AUTOSAR Meta Model
regarding parameter configuration. It allows easy access of modules, containers and values as well as
providing loops and verify a paramconf against a paramdef. These options are also available for postbuild.
PAGe is based on Python 3. It uses only modules of the standard library.
PAGe is designed for the usage with the BMW AUTOSAR Core modules.
Input files must have the ending .pgen which is removed from the output filename.
Usage
Generation
To generate a pgen file.
python3 -m page example.pgen
If arxmls should be used pass them to the commandline as well.
python3 -m page -o /tmp example.pgen input.arxml
Also multiple pgen files and arxml files work.
python3 -m page -o /tmp example1.pgen example2.pgen input.arxml input_new.arxml
Validation
In case you want to check a paramconf against its corresponding paramdef you can use the following
commandline
python3 -m page paramconf.arxml paramdef.arxml
The validation will be performed for all the variants if an ecuc configuration is provided, too.
python3 -m page paramconf.arxml paramdef.arxml ecuc.arxml
verb
To enable a more verbose output add -v to -vvvv to the command line.
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 4 of 22

2
Acronyms and Abbreviations
API
Application Programming Interface
Application Application stands for the high-level part of software that uses the APIs
provided by the modules. It can also mean the driving application that does
not belong to the Bootloader.
AUTOSAR Automotive Open System Architecture
OS
Operating System
PAGe
Python AUTOSAR Generator
pgen
Page generation file
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 5 of 22

3
Functionality
PAGe builds a model of the provided ARXML paramconf and paramdefs. Within the pgen files you have
access to this model and can navigate and retrieve values easily. Besides the access to the data you have
the full power of python.
Command Line Usage
Either you install page or you add the main directory to the source path. Installation can be achieved by
python3 setup.py install
after that the page command will be available. So you can call PAGe using:
page input.pgen test.arxml -vvvv
But you may want to do install page only in a virtualenv so it does not harm any other installation.
-o Specify the output directory, default is the current directory.
--stdout do not write files, print output to stdout instead.
-vvv change level of verbosity.
-l Location to write the logfile to. Default is stdout.
-m Specify delimiter to be used in pgen files. This allows you to specify other delimiters than the default
e.g. you have files, where the defaults have a special meaning and you don't like to escape the every
time used.
-d Enable debug mode (trap functions become active)
-V Verifies given paramconf against the paramdefs which ara supplied.
-i Add paths for the search of includes.
-D Pass variables to the pgen files (params dictionary)
-O Change the optimisedb. This database stores the hash and the filename, so file with no change will
not be overwritten.
-f Forces write of files, even if no output change has been detected.
Fileformat
The pgen files shall be utf-8 encoded files. The files shall use unix file endings, windows file endings \r\n
are transformed to \n.
A file consists of text and several blocks that are interpreted by PAGe. These blocks are enclosed by a
special sequence of characters. %{ marks the beginning of a block and }% marks the end. The first
character occuring directly after the opening tag has a special meaning an defines the type of the block.
The following distinct blocks are supported:
= The result of the statement within the tags are printed as output. A single statement shall be used but
can contain newline and indentiation. The result of the statement will appear in the output file.
# This marker indicates a section of code. The code can consist of any valid piece of python code and is
also able to use the access functions for the data of the ARXMLs. It can be indentiated and consist
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 6 of 22

of multiple lines. For indentiation the first line is taken for reference, the rest of the indentiation has
to follow Pythons rules.
: For conditions the colon is used as a marker. It occurs at least two times, one for the condition and one
time (without extra text) for the closure. This is needed for the correct handling. You still have to use
if, elif and else keywords.
? For quick conditionals you can use a question mark. It works also directly as output. The condition
followed by a colon which seperates it from the part which is written in case of success. And an
optional second colon to seperate the ouput in the case the condition is not fullfilled.
@ This one loops over a statement. You can loop over a number of container instances, or any other
python iterateable. To iterate over a python iterateable use the syntax myitem in mycontainer which
makes the current item available as myitem. For loop over arxml elements, please have a look at ??
+ Use the plus sign for including other pgen or python files. These files are included and interpreted at
the current point within the file which they are included. A file can be included several times. Pure
python files can be included, too. By default the current path of the currently leaded source files (or
included files) is used as search directory. You can add directories using the command line switch -i
This mark is for special handling of post build variation. It loops over the configured pre defined variants
that are configured for the ecu. Within the context of this mark, you have two special variables
available: predefined_variant_name which is the name of the current variant or None if no
variantation is configured. And predefined_variant_postfix which contains an underscore
followed by the variant name or an empty string else. This can be used to build the name of the
configuration according to ECUConfiguration.
Available Function and Objects
The following functions are provided as part of PAGe:
comment Format a given string as a comment in the current context. If no delimiter are given, the
functions calls the automatic delimiter resolution. The string is splitted into single lines and enclosed
in the delimiter
set_comment_delimiter Set the comment markers
count Count elements found by shortname/search expression.
current_file Get the current filename of the file processed (pgen file).
current_shortname Get the AUTOSAR shortname of the current scope.
current_shortname_path Get the AUTOSAR shortname path.
each Get unique shortname paths of the elements that match the given search expression.
exists Checks existence of elements specified by search expression or shortname in current context.
generation_file_fullpath Full path of the source file.
generation_file_modification Date of modification of the source file.
generation_info Info about the generation as dict.
generation_timestamp Timestamp of generation.
generation_tool name of the generation tool.
generation_version_info Version of Generator.
get_elements Get list of elements matching search expression.
get_xpaths Deprecated for get_elements.
into Change context to given target, resets if target is None. The scope is held in a stack
join Join a set of values referenced by the search expression.
leave Leave the current scope.
reset Resets the context to the root node.
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 7 of 22

set_debug Enable pdb debugging.
shortname Get the shortname at the given shortname path expression,
trap Traps if debugging is enabled.
value Fetching the value or value-ref of a search expression. Values are automatically casted to the
correct type.
write Write arguments to the output.
container Selects containers that refere to a given definition ref.
module Selects modules that refere to a given definition ref.
ref Get the elements in the model, which refere to the given shortnamepath as definition ref.
snpath Get the element at the given shortname path.
Additionally to the functions and objects there is a dictionary called params which contains parameters
passed to page by the command line (-D test=hello).
Handling of paramconf
In general when using the data of a paramconf you should never enter a specific path you expect to be in
the configuration. You should only use paths you define in the parameter definition or that are contained
in the configuration as value (value refs).
Notes ARXML shortcuts
The shortnamepaths snpath are looked up in the following order:
. return element
.. return parent
contains * Search children
startwith / lookup full path from root node
else lookup relative path
This means, whenever you want to get a grandchild of the current scope you need to prepend a star to
the node you are looking for or use the search.
Loops
In case you loop over VALUE or VALUE-REF elements, you can access its value using value() without a
target specified.
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 8 of 22

4
Examples
Basic Navigation
This example will demonstrate basic navigation through an ARXML document.
The example contains a module named MyModule which is of type TestModule and located in the
package /TestPackage/TestModule
It will demonstrate the following commands:
into
reset
ref
module
current_shortname_path
with
ARXML Files
input.arxml
<?xml version=’1.0’?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autosar.org/schema/r4.0 autosar.xsd">
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestPackage</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestModule</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>MyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/TestModule</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>NumericalValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/TestModule/
NumericalValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>5</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>8</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 9 of 22

<DEFINITION-REF DEST="ECUC-FLOAT-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueFloat</DEFINITION-REF>
<VALUE>3.1415</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>NotMyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/AnotherTestModule</DEFINITION-
REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>StringValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/
AnotherTestModule/StringValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-STRING-PARAM-DEF">/BMW_DEF/
AnotherTestModule/StringValues/ValueString</DEFINITION-REF>
<VALUE>Hello World the value is: </VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
pgen Files
input.pgen
%{# i n t o ( r e f ( ' TestModule ' ) ) }%
%{= current_shortname_path ( ) }%
This w i l l change i n t o the ∗FIRST∗ element found
%{# i n t o ( r e f ( ' V a l u e I n t ' ) ) }%
The shortname w i l l be taken from the p a r e n t element ,
as t h i s element i s not an i d e n t i f y a b l e .
%{= current_shortname_path ( ) }%
%{= v a l u e ( ) }%
%{# l e a v e ( ) }%
I f you expect more than one use a loop
For the loop the c o n t e x t i s a u t o m a t i c a l l y changed
%{@ r e f ( ' V a l u e I n t ' ) }%
%{= v a l u e ( ) }%
%{@}%
%{# i n t o ( r e f ( ' V a l u e F l o a t ' ) ) }%
%{= current_shortname_path ( ) }%
%{= v a l u e ( ) }%
%{# r e s e t ( ) }%
%{= current_shortname_path ( ) }%
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 10 of 22

%{# i n t o ( r e f ( ' TestModule ' ) ) }%
%{= current_shortname_path ( ) }%
%{# i n t o ( ) }%
%{= current_shortname_path ( ) }%
For a s h o r t i n t e r a c t i o n w i t h a c e r t a i n element w i t h i n a code block ,
you can a l s o use the w i t h statement o f python
%{#
w i t h module ( ' TestModule ' ) :
i n p u t = v a l u e ( r e f ( ' V a l u e F l o a t ' ) )
i n p u t = i n p u t ∗ 2
w i t h module ( ' AnotherTestModule ' ) :
s t r i n g = v a l u e ( r e f ( ' V a l u e S t r i n g ' ) )
}%
%{= ' { } { } ' . format ( s t r i n g , i n p u t ) }%
Command line
page −vvvv i n p u t . a r x m l i n p u t . pgen
Console Output
BMW PAGe
: INFO
Reading XML : i n p u t . a r x m l
BMW PAGe
: INFO
Reading XML took : 0.000859 s
BMW PAGe
: INFO
Reading a l l XMLs took : 0.00104 s
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 1 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00317 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 1 / i n p u t
File Output
/ TestPackage / TestModule / MyModule
This w i l l change i n t o the ∗FIRST∗ element found
The shortname w i l l be taken from the p a r e n t element ,
as t h i s element i s not an i d e n t i f y a b l e .
/ TestPackage / TestModule / MyModule / NumericalValues
5
I f you expect more than one use a loop
For the loop the c o n t e x t i s a u t o m a t i c a l l y changed
5
8
/ TestPackage / TestModule / MyModule / NumericalValues
3.1415
ROOT
/ TestPackage / TestModule / MyModule
ROOT
For a s h o r t i n t e r a c t i o n w i t h a c e r t a i n element w i t h i n a code block ,
you can a l s o use the w i t h statement o f python
H e l l o World the v a l u e i s :
6.283
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 11 of 22

Logging
This example will demonstrate the logging functionality.
There are several log levels that depend on the -vs provided on the command line.
It will demonstrate the following commands:
logger.debug
logger.info
logger.warning
logger.error
logger.fatal
pgen Files
input.pgen
Logging o f some i n f o r m a t i o n
%{# l o g g e r . debug ( ' This i s a message f o r debugging so you have to s p e c i f y a few v on the command l i n e ' ) }%
%{# l o g g e r . i n f o ( ' This t e x t w i l l appear i n the INFO log ' ) }%
%{# l o g g e r . warning ( ' You ' ' ve been warned ')}%
%{# l o g g e r . e r r o r ( ' This w i l l not work , ok I \ ' l l l e t you continue ')}%
%{# l o g g e r . f a t a l ( ' Oh noooo ! ' ) } %
Command line
page −vvvv i n p u t . pgen
Console Output
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 2 / i n p u t . pgen
BMW PAGe
: DEBUG
This i s a message f o r debugging so you have to s p e c i f y a few v on the command l i n e
BMW PAGe
: INFO
This t e x t w i l l appear i n the INFO l o g
BMW PAGe
: WARNING
Youve been warned
BMW PAGe
: ERROR
This w i l l not work , ok I ' l l l e t you continue
BMW PAGe
: CRITICAL Oh noooo !
BMW PAGe
: INFO
Processing Pgen took : 0.00185 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 2 / i n p u t
File Output
Logging o f some i n f o r m a t i o n
Usage of Code Blocks
This example will show a few details about the code block
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 12 of 22

The code block is one of PAGes super power. It allows to use any python code from within it. You can still
use PAGes functions but also any other python statement you could think of.
It will demonstrate the following commands:
write
CodeBlock
pgen Files
input.pgen
Usage o f Code Blocks
Besides the output blocks you can use code blocks :
%{#
# The f i r s t l i n e d e f i n e s the b a s i c i n d e n t i a t i o n .
# a l l l i n e s are i n t e r p r e t e d as pure python .
def MyFunction ( a , b ) :
r e t u r n ( a+b ) ∗ b
}%
A l l v a r i a b l e s , f u n c t i o n s , ect . w i l l remain u n t i l the end o f the pgen f i l e .
You can now see the r e s u l t o f the p r e v i o u s f u n c t i o n : %{= MyFunction ( 3 , 5 ) }%
I f you want to w r i t e to the output from w i t h i n a code block , you should use the ∗ w r i t e ∗ command
%{#
f o r x i n range ( 1 , 1 5 ) :
i f ' 3 ' i n s t r ( x ) or x % 3 == 0 :
w r i t e ( ' buzz \ n ' )
e l s e :
w r i t e ( ' { } \ n ' . format ( x ) )
}%
NB : w r i t e does not a u t o m a t i c a l l y add a newline .
Command line
page −vvvv i n p u t . pgen
Console Output
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 3 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00171 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 3 / i n p u t
File Output
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 13 of 22

Usage o f Code Blocks
Besides the output blocks you can use code blocks :
A l l v a r i a b l e s , f u n c t i o n s , ect . w i l l remain u n t i l the end o f the pgen f i l e .
You can now see the r e s u l t o f the p r e v i o u s f u n c t i o n : 40
I f you want to w r i t e to the output from w i t h i n a code block , you should use the ∗ w r i t e ∗ command
1
2
buzz
4
5
buzz
7
8
buzz
10
11
buzz
buzz
14
NB : w r i t e does not a u t o m a t i c a l l y add a newline .
Conditionals
This example will show the usage of conditional parts within a pgen file
The example contains a module named MyModule which is of type TestModule and located in the
package /TestPackage/TestModule
It will demonstrate the following commands:
if
elif
else
ShortIfBlock
ConditionalBlock
value
ARXML Files
input.arxml
<?xml version=’1.0’?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 14 of 22

xsi:schemaLocation="http://autosar.org/schema/r4.0 autosar.xsd">
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestPackage</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>MyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/TestModule</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>NumericalValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/TestModule/
NumericalValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>5</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
pgen Files
input.pgen
C o n d i t i o n a l s can be done as seen here :
%{: i f v a l u e ( r e f ( ' V a l u e I n t ' ) ) < 6 }%
Test
%{: e l i f e x i s t s ( r e f ( ' V a l u e F l o a t ' ) ) }%
This w i l l not occur i n the output
%{: e l s e }%
This won ' t appear
%{:}%
Want some s h o r t e r i f ?
These w r i t e the t e x t provided dependent on the r e s u l t o f the statement e v a l u a t i o n
# Both o p t i o n s provided
True :
%{? True : For sure ! : Nooooo!}%
False : %{? False : For sure ! : Nooooo!}%
# No i s not an o p t i o n
True :
%{? True : For sure !}%
False : %{? False : For sure !}%
# Only output something i f the r e s u l t i s f a l s e
True :
%{? True : : NO! ! ! ! } %
False : %{? False : : NO! ! ! ! } %
Command line
page −vvvv i n p u t . a r x m l i n p u t . pgen
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 15 of 22

Console Output
BMW PAGe
: INFO
Reading XML : i n p u t . a r x m l
BMW PAGe
: INFO
Reading XML took : 0.000677 s
BMW PAGe
: INFO
Reading a l l XMLs took : 0.000871 s
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 4 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00211 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 4 / i n p u t
File Output
C o n d i t i o n a l s can be done as seen here :
Test
Want some s h o r t e r i f ?
These w r i t e the t e x t provided dependent on the r e s u l t o f the statement e v a l u a t i o n
# Both o p t i o n s provided
True :
For sure !
False : Nooooo !
# No i s not an o p t i o n
True :
For sure !
False :
# Only output something i f the r e s u l t i s f a l s e
True :
False : NO ! ! ! !
More Functions
This example will contain usages of different functions.
The example contains a module named MyModule which is of type TestModule and located in the
package /TestPackage/TestModule
It will demonstrate the following commands:
count
current_shortname
exists
with
ARXML Files
input.arxml
<?xml version=’1.0’?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autosar.org/schema/r4.0 autosar.xsd">
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 16 of 22

<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestPackage</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestModule</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>MyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/TestModule</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>NumericalValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/TestModule/
NumericalValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>5</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>8</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-FLOAT-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueFloat</DEFINITION-REF>
<VALUE>3.1415</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>NotMyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/AnotherTestModule</DEFINITION-
REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>StringValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/
AnotherTestModule/StringValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-STRING-PARAM-DEF">/BMW_DEF/
AnotherTestModule/StringValues/ValueString</DEFINITION-REF>
<VALUE>Hello World the value is: </VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 17 of 22

pgen Files
input.pgen
%{# i n t o ( r e f ( ' TestModule ' ) ) }%
%{= current_shortname_path ( ) }%
We can a l s o check the number o f elements :
There are %{= count ( r e f ( ' V a l u e I n t ' ) ) }% V a l u e I n t elements .
There e x i s t s a t l e a s t one V a l u e F l o a t : %{= e x i s t s ( r e f ( ' V a l u e F l o a t ' ) ) }%.
You can use the p r e v i o u s o p t i o n s a l s o as an asignment statement :
%{# pre viou s_sn = current_shortname ( ) }%
%{# l e a v e ()}%
and use i t l a t e r
%{= pr evio us_s n }%
Command line
page −vvvv i n p u t . a r x m l i n p u t . pgen
Console Output
BMW PAGe
: INFO
Reading XML : i n p u t . a r x m l
BMW PAGe
: INFO
Reading XML took : 0.0012 s
BMW PAGe
: INFO
Reading a l l XMLs took : 0.00162 s
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 5 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00212 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 5 / i n p u t
File Output
/ TestPackage / TestModule / MyModule
We can a l s o check the number o f elements :
There are 2 V a l u e I n t elements .
There e x i s t s a t l e a s t one V a l u e F l o a t : 1 .
You can use the p r e v i o u s o p t i o n s a l s o as an asignment statement :
and use i t l a t e r
MyModule
ARXML Stuff
This example will demonstrate some more ARXML selection stuff which can be usefull.
It will demonstrate the following commands:
into
module
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 18 of 22

each
container
ref
snpath
ARXML Files
input.arxml
<?xml version=’1.0’?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autosar.org/schema/r4.0 autosar.xsd">
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestPackage</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestModule</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>MyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/TestModule</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>NumericalValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/TestModule/
NumericalValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>5</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>8</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-FLOAT-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueFloat</DEFINITION-REF>
<VALUE>3.1415</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>NotMyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/AnotherTestModule</DEFINITION-
REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>StringValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/
AnotherTestModule/StringValues</DEFINITION-REF>
<PARAMETER-VALUES>
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 19 of 22

<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-STRING-PARAM-DEF">/BMW_DEF/
AnotherTestModule/StringValues/ValueString</DEFINITION-REF>
<VALUE>Hello World the value is: </VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/BMW_DEF/AnotherTestModule/
StringValues/ReferenceToNumericals</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/TestPackage/TestModule/
MyModule/NumericalValues</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
pgen Files
input.pgen
Find a Module and change the c u r r e n t scope to i t
%{# i n t o ( module ( ' TestModule ' ) ) }%
The next element to get to i s a ( sub ) c o n t a i n e r
%{# i n t o ( c o n t a i n e r ( ' NumericalValues ' ) ) }%
But we need a d i f f e r e n t c o n t a i n e r
%{#
r e s e t ( )
i n t o ( c o n t a i n e r ( ' AnotherTestModule / S t r i n g V a l u e s ' ) )
}%
You can search f o r elements references , too :
%{= v a l u e ( r e f ( ' ReferenceToNumericals ' ) ) }%
You can use these to go i n t o but you have to use v a l u e
to get the s t r i n g o f the r e f e r e n c e
%{# i n t o ( v a l u e ( r e f ( ' ReferenceToNumericals ' ) ) ) }%
%{= current_shortname_path ( ) }%
%{# r e s e t ( ) }%
Command line
page −vvvv i n p u t . a r x m l i n p u t . pgen
Console Output
BMW PAGe
: INFO
Reading XML : i n p u t . a r x m l
BMW PAGe
: INFO
Reading XML took : 0.00095 s
BMW PAGe
: INFO
Reading a l l XMLs took : 0.00114 s
BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 20 of 22

BMW PAGe
: INFO
Open f i l e / 0 0 6 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00228 s
BMW PAGe
: INFO
F i l e does not e x i s t
BMW PAGe
: INFO
Wr ite / 0 0 6 / i n p u t
File Output
Find a Module and change the c u r r e n t scope to i t
The next element to get to i s a ( sub ) c o n t a i n e r
But we need a d i f f e r e n t c o n t a i n e r
You can search f o r elements references , too :
/ TestPackage / TestModule / MyModule / NumericalValues
You can use these to go i n t o but you have to use v a l u e
to get the s t r i n g o f the r e f e r e n c e
/ TestPackage / TestModule / MyModule / NumericalValues
Filtering Elements
This example will demonstrate some techniques that can be used to filter some elements out of a larger
list.
It will demonstrate the following commands:
into
reset
ref
module
current_shortname_path
with
ARXML Files
input.arxml
<?xml version=’1.0’?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autosar.org/schema/r4.0 autosar.xsd">
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestPackage</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>TestModule</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>MyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/TestModule</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>NumericalValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/TestModule/
NumericalValues</DEFINITION-REF>
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 21 of 22

<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>5</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueInt</DEFINITION-REF>
<VALUE>8</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-FLOAT-PARAM-DEF">/BMW_DEF/TestModule/
NumericalValues/ValueFloat</DEFINITION-REF>
<VALUE>3.1415</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>NotMyModule</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/BMW_DEF/AnotherTestModule</DEFINITION-
REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>StringValues</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/BMW_DEF/
AnotherTestModule/StringValues</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-STRING-PARAM-DEF">/BMW_DEF/
AnotherTestModule/StringValues/ValueString</DEFINITION-REF>
<VALUE>Hello World the value is: </VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR>
pgen Files
input.pgen
Command line
page −vvvv i n p u t . a r x m l i n p u t . pgen
Console Output
BMW PAGe
: INFO
Reading XML : i n p u t . a r x m l
BMW PAGe
: INFO
Reading XML took : 0.000903 s
BMW PAGe
: INFO
Reading a l l XMLs took : 0.00111 s
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 22 of 22

BMW PAGe
: INFO
processing Pgen : i n p u t . pgen
BMW PAGe
: INFO
Open f i l e / 0 0 7 / i n p u t . pgen
BMW PAGe
: INFO
Processing Pgen took : 0.00141 s
BMW PAGe
: INFO
Empty content −> no f i l e w r i t t e n
BMW PAGe
: INFO
Skipping w r i t e o f / 0 0 7 / i n p u t , no changes detected
File Output
UserGuide_PAGe, Version 1.1.0, Software Platforms
Page 23 of 22
Document Outline
- 1 Overview
- 2 Acronyms and Abbreviations
- 3 Functionality
- 4 Examples
6.1 - pylint.1
- pylint(1)
- Python Script Verification Tool
- pylint(1)
NAME
pylint - Python Script Verification Utility
SYNOPSIS
pylint [ OPTIONS ] [ arguments ]
DESCRIPTION
pylint is a Python source code analyzer which looks for programming errors, helps enforcing a coding standard and
sniffs for some code smells (as defined in Martin Fowler's Refactoring book).
Nexteer did not create nor does it maintain pylint. This page was copied from
the Linux manpage for pylint. Nexteer did, however, add
[a section below][#INSTALLATION] regarding configuration of the tool for use on Nexteer tools/scripts.
OPTIONS
- --version
- Show program's version number and exit. 
- --help,- -h
- Show this help message and exit. 
- --long-help
- Print a more verbose help. 
MASTER
- --rcfile=<file>
- Specify a configuration file. 
- --init-hook=<code>
- Python code to execute, usually for sys.path manipulation such as pygtk.require(). 
- --errors-only,- -E
- In error mode, checkers without error messages are disabled and for others, only the ERROR messages are displayed, and no reports are done by default. 
- --ignore=<file>
- Add file or directory to the black list. It should be a base name, not a path. You may set this option multiple times. [default: CVS] 
- --persistent=<y_or_n>
- Pickle collected data for later comparisons. [default: yes] 
- --load-plugins=<modules>
- List of plugins (as comma separated values of python modules names) to load, usually to register additional checkers. [default: none] 
COMMANDS
- --help-msg=<msg-id>
- Display a help message for the given message id and exit. The value may be a comma separated list of message ids. 
- --list-msgs
- Generate pylint's messages. 
- --full-documentation
- Generate pylint's full documentation. 
- --generate-rcfile
- Generate a sample configuration file according to the default configuration. You can put other options before this one to get them in the generated configuration. 
MESSAGES CONTROL
- --enable=<msg ids>,- -e <msg ids>
- Enable the message, report, category or checker with the given id(s). You can either give multiple identifier separated by comma (,) or put this option multiple time. 
- --disable=<msg ids>,- -d <msg ids>
- Disable the message, report, category or checker with the given id(s). You can either give multiple identifier separated by comma (,) or put this option multiple time. 
REPORTS
- --output-format=<format>,- -f <format>
- Set the output format. Available formats are text, parseable, colorized, msvs (visual studio) and html. [default: text] 
- --include-ids=<y_or_n>,- -i <y_or_n>
- Include message's id in output. [default: no] 
- --files-output=<y_or_n>
- Put messages in a separate file for each module / package specified on the command line instead of printing them on stdout. Reports (if any) will be written in a file name "pylint_global.[txt|html]". [default: no] 
- --reports=<y_or_n>,- -r <y_or_n>
- Tells whether to display a full report or only the messages. [default: yes] 
- --evaluation=<python_expression>
- Python expression which should return a note less than 10 (10 is the highest note). You have access to the variables errors warning, statement which respectively contain the number of errors / warnings messages and the total number of statements analyzed. This is used by the global evaluation report (R0004). [default: 10.0 - ((float(5 * error + warning + refactor + convention) / statement) * 10)] 
- --comment=<y_or_n>
- Add a comment according to your evaluation note. This is used by the global evaluation report (R0004). [default: no] 
BASIC
- --required-attributes=<attributes>
- Required attributes for module, separated by a comma [default: none] 
- --bad-functions=<builtin function names>
- List of builtins function names that should not be used, separated by a comma. [default: map, filter, apply, input] 
- --module-rgx=<regexp>
- Regular expression which should only match correct module names. [default: (([a-z][a-z0-9]*)|([A-Z][a-zA-Z0-9]+))$] 
- --const-rgx=<regexp>
- Regular expression which should only match correct module level names. [default: (([a-zA-Z][A-Z0-9])|(__.__))$] 
- --class-rgx=<regexp>
- Regular expression which should only match correct class names. [default: [A-Z_][a-zA-Z0-9]+$] 
- --function-rgx=<regexp>
- Regular expression which should only match correct function names. [default: [a-z][a-z0-9]{2,30}$] 
- --method-rgx=<regexp>
- Regular expression which should only match correct method names. [default: [a-z][a-z0-9]{2,30}$] 
- --attr-rgx=<regexp>
- Regular expression which should only match correct instance attribute names. [default: [a-z][a-z0-9]{2,30}$] 
- --argument-rgx=<regexp>
- Regular expression which should only match correct argument names. [default: [a-z][a-zA-Z0-9]{2,30}$] 
- --variable-rgx=<regexp>
- Regular expression which should only match correct variable names. [default: [a-z][a-zA-Z0-9]{2,30}$] 
- --inlinevar-rgx=<regexp>
- Regular expression which should only match correct list comprehension / generator expression variable names. [default: [A-Za-z][A-Za-z0-9]*$] 
- --good-names=<names>
- Good variable names which should always be accepted, separated by a comma. [default: i,j,k,ex,Run,_] 
- --bad-names=<names>
- Bad variable names which should always be refused, separated by a comma. [default: foo, bar, baz, toto, tutu, tata] 
- --no-docstring-rgx=<regexp>
- Regular expression which should only match functions or classes name which do not require a docstring. [default: .*] 
MISCELLANEOUS
- --notes=<comma separated values>
- List of note tags to take in consideration, separated by a comma. [default: FIXME,XXX,TODO]
SIMILARITIES
- --min-similarity-lines=<int>
- Minimum lines number of a similarity. [default: 4] 
- --ignore-comments=<y or n>
- Ignore comments when computing similarities. [default: yes] 
- --ignore-docstrings=<y or n>
- Ignore docstrings when computing similarities. [default: yes] 
IMPORTS
- --deprecated-modules=<modules>
- Deprecated modules which should not be used, separated by a comma. [default: regsub, string, TERMIOS, Bastion, rexec] 
- --import-graph=<file.dot>
- Create a graph of every (i.e. internal and external) dependencies in the given file (report RP0402 must not be disabled). [default: none] 
- --ext-import-graph=<file.dot>
- Create a graph of external dependencies in the given file (report RP0402 must not be disabled). [default: none] 
- --int-import-graph=<file.dot>
- Create a graph of internal dependencies in the given file (report RP0402 must not be disabled). [default: none] 
TYPECHECK
- --ignore-mixin-members=<y_or_n>
- Tells whether missing members accessed in mixin class should be ignored. A mixin class is detected if its name ends with "mixin" (case insensitive). [default: yes] 
- --ignored-classes=<members names>
- List of classes names for which member attributes should not be checked (useful for classes with attributes dynamically set). [default: SQLObject] 
- --zope=<y_or_n>
- When zope mode is activated, add a predefined set of Zope acquired attributes to generated-members. [default: no] 
- --generated-members=<members names>
- List of members which are set dynamically and missed by pylint inference system, and so shouldn't trigger E0201 when accessed. [default: REQUEST, acl_users, aq_parent] 
CLASSES
- --ignore-iface-methods=<method names>
- List of interface methods to ignore, separated by a comma. This is used for instance to not check methods defines in Zope's Interface base class. [default: isImplementedBy, deferred, extends, names, namesAndDescriptions, queryDescriptionFor, getBases, getDescriptionFor, getDoc, getName, getTaggedValue, getTaggedValueTags, isEqualOrExtendedBy, setTaggedValue, isImplementedByInstancesOf, adaptWith, is_implemented_by] 
- --defining-attr-methods=<method names>
- List of method names used to declare (i.e. assign) instance attributes. [default: init,new,setUp] 
DESIGN
- --max-args=<int>
- Maximum number of arguments for function / method. [default: 5] 
- --ignored-argument-names=<regexp>
- Argument names that match this expression will be ignored. Default to name with leading underscore. [default: _.*] 
- --max-locals=<int>
- Maximum number of locals for function / method body. [default: 15] 
- --max-returns=<int>
- Maximum number of return / yield for function / method body. [default: 6] 
- --max-branchs=<int>
- Maximum number of branch for function / method body. [default: 12] 
- --max-statements=<int>
- Maximum number of statements in function / method body. [default: 50] 
- --max-parents=<num>
- Maximum number of parents for a class (see R0901). [default: 7] 
- --max-attributes=<num>
- Maximum number of attributes for a class (see R0902). [default: 7] 
- --min-public-methods=<num>
- Minimum number of public methods for a class (see R0903). [default: 2] 
- --max-public-methods=<num>
- Maximum number of public methods for a class (see R0904). [default: 20] 
VARIABLES
- --init-import=<y_or_n>
- Tells whether we should check for unused import in init files. [default: no] 
- --dummy-variables-rgx=<regexp>
- A regular expression matching names used for dummy variables (i.e. not used). [default: _|dummy] 
- --additional-builtins=<comma separated list>
- List of additional names supposed to be defined in builtins. Remember that you should avoid to define new builtins when possible. [default: none] 
FORMAT
- --max-line-length=<int>
- Maximum number of characters on a single line. [default: 120] 
- --max-module-lines=<int>
- Maximum number of lines in a module. [default: 1000] 
- --indent-string=<string>
- String used as indentation unit. This is usually " " (4 spaces) or "t" (1 tab). [default: ' '] 
ENVIRONMENT VARIABLES
The following environment variables are used:
- PYLINTHOME
- Path to the directory where data of persistent run will be stored. If not found, it defaults to ~/.pylint.d/ or .pylint.d (in the default working directory). 
- PYLINTRC
- Path to the configuration file. If not found, it will use the first existent file in ~/.pylintrc, /etc/pylintrc. 
OUTPUT
Using the default text output, the message format is:
MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE
There are 5 kind of message types:
- (C)convention, for programming standard violation.
- (R)refactor, for bad code smell.
- (W)warning, for python specific problems.
- (E)error, for probable bugs in the code.
- (F)fatal, if an error occurred which prevented pylint from doing further processing.
RETURN CODE
Pylint should leave with following status code:
- 0if everything went fine.
- 1if a fatal message was issued.
- 2if an error message was issued.
- 4if a warning message was issued.
- 8if a refactor message was issued.
- 16if a convention message was issued.
- 32on usage error
Status 1 to 16 will be bit-OR'd so you can know which different categories has been issued by analyzing pylint output
status code.
INSTALLATION
To setup pylint, copy the configuration file (.pylintrc) from the TL112A_Python\doc folder and place a copy in your
user folder (C:\User\username). Pylint will automatically determine this path when invoked and use the settings from
the file located there. Alternatively, you can manually specify the path to the config file when invoking pylint by
using the --rcfile=<rcfile> switch.
DOCUMENTATION
This documentation was generated using ronn. ronn converts a text file with a
format similar to Markdown into an HTML file with a format typical of a standard manpage. For more information about
ronn see it's manpage: ronn(1). For more information on the syntax see
that manpage: ronn-format(7).
COPYRIGHT
(c) 2017 Nexteer Automotive
- Nexteer Automotive
- July 2017
- pylint(1)
6.2 - TL112A_Python Peer Review Checklist
Overview
Summary SheetSynergy Project
Sheet 1: Summary Sheet

Sheet 2: Synergy Project
6.3 - sgml_input
| 
 | 
 | 
| Flotas (max. 9) | |||||||
| Num. | Misin | Cantidad | Comienzo | Salida | Objetivo | Llegada | Orden | 
|---|---|---|---|---|---|---|---|
| 1 | Espionaje (F) | 3 | [2:250:6] | Wed Aug 9 18:00:02 | [2:242:5] | Wed Aug 9 18:01:02 | |
| 2 | Espionaje (V) | 3 | [2:250:6] | Wed Aug 9 17:59:55 | [2:242:1] | Wed Aug 9 18:01:55 | |
6.4 - test_difflib_expect
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
| 42 | 123 | 42 | 123 | ||
| 43 | 123 | 43 | 123 | ||
| 44 | 123 | 44 | 123 | ||
| 45 | 123 | 45 | 123 | ||
| Legends | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 
 | 
 | |||||||||
Context (first diff within numlines=5(default))
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
Context (first diff after numlines=5(default))
| from | to | ||||
|---|---|---|---|---|---|
| 7 | 456 | 7 | 456 | ||
| 8 | 456 | 8 | 456 | ||
| 9 | 456 | 9 | 456 | ||
| 10 | 456 | 10 | 456 | ||
| 11 | 11 | ||||
| n | 12 | 1. Beautiful is beTTer than ugly. | n | 12 | 1. Beautiful is better than ugly. | 
| 13 | 2. Explicit is better than implicit. | ||||
| 14 | 3. Simple is better than complex. | 13 | 3. Simple is better than complex. | ||
| 15 | 4. Complex is better than complicated. | 14 | 4. Complicated is better than complex. | ||
| 15 | 5. Flat is better than nested. | ||||
| 16 | 123 | 16 | 123 | ||
| 17 | 123 | 17 | 123 | ||
| 18 | 123 | 18 | 123 | ||
| 19 | 123 | 19 | 123 | ||
| 20 | 123 | 20 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 26 | ||||
| n | 27 | 1. Beautiful is beTTer than ugly. | n | 27 | 1. Beautiful is better than ugly. | 
| 28 | 2. Explicit is better than implicit. | ||||
| 29 | 3. Simple is better than complex. | 28 | 3. Simple is better than complex. | ||
| 30 | 4. Complex is better than complicated. | 29 | 4. Complicated is better than complex. | ||
| 30 | 5. Flat is better than nested. | ||||
| 31 | 123 | 31 | 123 | ||
| 32 | 123 | 32 | 123 | ||
| 33 | 123 | 33 | 123 | ||
| 34 | 123 | 34 | 123 | ||
| 35 | 123 | 35 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 41 | ||||
| t | 42 | 1. Beautiful is beTTer than ugly. | t | 42 | 1. Beautiful is better than ugly. | 
| 43 | 2. Explicit is better than implicit. | ||||
| 44 | 3. Simple is better than complex. | 43 | 3. Simple is better than complex. | ||
| 45 | 4. Complex is better than complicated. | 44 | 4. Complicated is better than complex. | ||
| 45 | 5. Flat is better than nested. | ||||
| 46 | 123 | 46 | 123 | ||
| 47 | 123 | 47 | 123 | ||
| 48 | 123 | 48 | 123 | ||
| 49 | 123 | 49 | 123 | ||
| 50 | 123 | 50 | 123 | ||
Context (numlines=6)
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
Context (numlines=0)
| from | to | ||||
|---|---|---|---|---|---|
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
Same Context
| from | to | ||||
|---|---|---|---|---|---|
| t | No Differences Found | t | No Differences Found | ||
Same Full
| from | to | ||||
|---|---|---|---|---|---|
| t | 1 | t | 1 | ||
| 2 | 1. Beautiful is beTTer than ugly. | 2 | 1. Beautiful is beTTer than ugly. | ||
| 3 | 2. Explicit is better than implicit. | 3 | 2. Explicit is better than implicit. | ||
| 4 | 3. Simple is better than complex. | 4 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 5 | 4. Complex is better than complicated. | ||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| 17 | 1. Beautiful is beTTer than ugly. | 17 | 1. Beautiful is beTTer than ugly. | ||
| 18 | 2. Explicit is better than implicit. | 18 | 2. Explicit is better than implicit. | ||
| 19 | 3. Simple is better than complex. | 19 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 20 | 4. Complex is better than complicated. | ||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| 32 | 1. Beautiful is beTTer than ugly. | 32 | 1. Beautiful is beTTer than ugly. | ||
| 33 | 2. Explicit is better than implicit. | 33 | 2. Explicit is better than implicit. | ||
| 34 | 3. Simple is better than complex. | 34 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 35 | 4. Complex is better than complicated. | ||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
| 42 | 123 | 42 | 123 | ||
| 43 | 123 | 43 | 123 | ||
| 44 | 123 | 44 | 123 | ||
| 45 | 123 | 45 | 123 | ||
Empty Context
| from | to | ||||
|---|---|---|---|---|---|
| t | No Differences Found | t | No Differences Found | ||
Empty Full
| from | to | ||||
|---|---|---|---|---|---|
| t | Empty File | t | Empty File | ||
tabsize=2
| f | 1 | f | 1 | ||
| t | 2 | Line 1: preceeded by from:[tt] to:[ssss] | t | 2 | Line 1: preceeded by from:[tt] to:[ssss] | 
| 3 | Line 2: preceeded by from:[sstt] to:[sssst] | 3 | Line 2: preceeded by from:[sstt] to:[sssst] | ||
| 4 | Line 3: preceeded by from:[sstst] to:[ssssss] | 4 | Line 3: preceeded by from:[sstst] to:[ssssss] | ||
| 5 | Line 4: has from:[sst] to:[sss] after : | 5 | Line 4: has from:[sst] to:[sss] after : | ||
| 6 | Line 5: has from:[t] to:[ss] at end | 6 | Line 5: has from:[t] to:[ss] at end | 
tabsize=default
| f | 1 | f | 1 | ||
| t | 2 | Line 1: preceeded by from:[tt] to:[ssss] | t | 2 | Line 1: preceeded by from:[tt] to:[ssss] | 
| 3 | Line 2: preceeded by from:[sstt] to:[sssst] | 3 | Line 2: preceeded by from:[sstt] to:[sssst] | ||
| 4 | Line 3: preceeded by from:[sstst] to:[ssssss] | 4 | Line 3: preceeded by from:[sstst] to:[ssssss] | ||
| 5 | Line 4: has from:[sst] to:[sss] after : | 5 | Line 4: has from:[sst] to:[sss] after : | ||
| 6 | Line 5: has from:[t] to:[ss] at end | 6 | Line 5: has from:[t] to:[ss] at end | 
Context (wrapcolumn=14,numlines=0)
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | 
wrapcolumn=14,splitlines()
| f | 1 | line 0 | f | 1 | line 0 | 
| 2 | 12345678901234 | 2 | 12345678901234 | ||
| > | 56789012345689 | > | 56789012345689 | ||
| > | 012345 | > | 012345 | ||
| 3 | line 1 | 3 | line 1 | ||
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| 5 | line 3 | 5 | line 3 | ||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| 9 | line 7 | 9 | line 7 | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| 11 | line 9 | 11 | line 9 | ||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | ||
| 16 | the end | 16 | the end | 
wrapcolumn=14,splitlines(True)
| f | 1 | line 0 | f | 1 | line 0 | 
| 2 | 12345678901234 | 2 | 12345678901234 | ||
| > | 56789012345689 | > | 56789012345689 | ||
| > | 012345 | > | 012345 | ||
| 3 | line 1 | 3 | line 1 | ||
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| 5 | line 3 | 5 | line 3 | ||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| 9 | line 7 | 9 | line 7 | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| 11 | line 9 | 11 | line 9 | ||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | ||
| 16 | the end | 16 | the end | 
7.1 - Python3_Review
Overview
Summary SheetSynergy Project
help
Version History
Sheet 1: Summary Sheet
| Rev 2.01 | 21-Feb-18 | |||||||||||||||||||||||||||||
| Nexteer EA4 SWC Implementation Peer Review Summary Sheet | ||||||||||||||||||||||||||||||
| Component Short Name: | Python3 | Revision / Baseline: | TL119A_Python3_3.6.4_0 | |||||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Work CR ID: | EA4#20630 | |||||||||||||||||||||||||||
| Modified File Types: | ||||||||||||||||||||||||||||||
| Check the file types that needed modification for the Work CR(s); macros for the check boxes will populate the appropriate checklist tabs for the review. | ||||||||||||||||||||||||||||||
| Review Checklist Summary: | ||||||||||||||||||||||||||||||
| Reviewed: | ||||||||||||||||||||||||||||||
| At start of review, all items below should be marked "No". At the end of the review, all items should be marked "Yes" or "N/A" where N/A indicates the reviewers have reviewed the existing (unchanged) item and confirmed no updates were needed for the Work CR(s). | ||||||||||||||||||||||||||||||
| N/A | MDD | N/A | Source Code | N/A | PolySpace | |||||||||||||||||||||||||
| N/A | Integration Manual | N/A | Davinci Files | |||||||||||||||||||||||||||
| All required reviewers participated | ||||||||||||||||||||||||||||||
| Comments: | Python is a 3rd party application.Review was to ensure all files needed were accounted for. | |||||||||||||||||||||||||||||
| Time spent ( to the nearest half hour) | review preparation | review meeting | review follow-up | |||||||||||||||||||||||||||
| Change owner: | 0.5 | 0.5 | 0 | |||||||||||||||||||||||||||
| Component developer reviewers: | 0 | 0 | 0 | 1 | ||||||||||||||||||||||||||
| Other reviewers: | 0 | 0 | 0 | |||||||||||||||||||||||||||
| Total hours | 0.5 | 0.5 | 0 | 1 | ||||||||||||||||||||||||||
| Content reviewed | ||||||||||||||||||||||||||||||
| Lines of code: | Elements of .arxml content: | Pages of 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 SWC Owner and/or SWC Design author and Integrator and/or SW Lead 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. Each peer review shall start with a clean copy of the latest peer review checklist template. Save in the doc folder of the component implementation, with the file name in the format SWCShortName_Review.xlsx. If the existing review in Synergy has a different name, the name must be changed IN SYNERGY (rather than by syncing in a new file with the new name) so that the file history will be properly maintained. Before the peer review, the change owner shall: (NOTE - time for completing these items is to be counted as the Change Owner Review Prep Time) o Review the previous component peer review and copy any relevant comments to the new review sheet. o Review all checklist items and make all corrections needed, so that the component is ready for peer review. The expectation is that peer review should find very few issues, because the change owner has already used the checklist to ensure the component changes are complete and correct. o Fill in all file name and version information as needed on peer review checklist tabs (file names may be copied from the previous peer review where appropriate) o Fill in checklist answers (Yes/No/NA pulldowns) ONLY on those items which are NA for the current change. All other checklist items should be blank going into the review meeting. During the peer review meeting: o For each page of the review, first review the items already marked as N/A for this change, to confirm that reviewers agree with this assessment; change the checklist box to blank if it is found that the item does apply. o Then review the items with the checklist box blank. After reviewing each of these items, the checklist box will be marked as "Yes", or the checklist box will be marked as "No" with needed rework indicated or with rationale indicated. o If any items are marked "No" with rationale indicated, this must be approved by a software supervisor or the software manager; there is a line in the "Review Board" section of each tab to indicate who approved the "No" items on that tab. | ||||||||||||||||||||||||||||||
 
 
 
 

Sheet 2: Synergy Project
| Rev 2.01 | 21-Feb-18 | |||||||||||||||||||||||
| Peer Review Meeting Log (Component Synergy Project Review) | ||||||||||||||||||||||||
| Quality Check Items: | ||||||||||||||||||||||||
| Rationale is required for all answers of No | ||||||||||||||||||||||||
| New baseline version name from Summary Sheet follows | Yes | Comments: | ||||||||||||||||||||||
| naming convention | ||||||||||||||||||||||||
| Project contains necessary subprojects | Yes | Comments: | No additioanl subprojects were needed | |||||||||||||||||||||
| Project contains the correct version of subprojects | N/A | Comments: | No additional subprojects required | |||||||||||||||||||||
| Design subproject is correct version | N/A | Comments: | Not required for tool component | |||||||||||||||||||||
| .gpj file in tools folder matches .gpj generated by TL109 script | N/A | Comments: | Not required for tool component | |||||||||||||||||||||
| File/folder structure is correct per documentation in | N/A | Comments: | Not required for tool component | |||||||||||||||||||||
| TL109A_SwcSuprt | ||||||||||||||||||||||||
| General Notes / Comments: | ||||||||||||||||||||||||
| Python is a 3rd party component. Files were taken exactly as received. | ||||||||||||||||||||||||
| Review Board: | ||||||||||||||||||||||||
| Change Owner: | Kevin Smith | Review Date : | 03/15/18 | |||||||||||||||||||||
| Lead Peer Reviewer: | Shameel M. | Approved by Reviewer(s): | Yes | |||||||||||||||||||||
| Other Reviewer(s): | ||||||||||||||||||||||||
| Rationale/justification for items marked "No" approved by: | ||||||||||||||||||||||||
Sheet 3: help
| Summary sheet: | |||||||||||||||
| Intended Use: Identify which component is being reviewed. This should match the component short name from the DataDict.m fileand the middle part of the Synergy project name, e.g. Assi for the SF001A_Assi_Impl Synergy project | |||||||||||||||
| Intended Use: Identify the implementation baseline name intended to be used for the changed component when changes are approved E.g. SF001A_Assi_Impl_1.2.0 | |||||||||||||||
| Intended Use: Identify the developer who made the change(s) being reviewed | |||||||||||||||
| Intended Use: Identify the Implementation Work CR whose work is being reviewed (may be more than one) | |||||||||||||||
| Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. | |||||||||||||||
| Source code: | |||||||||||||||
| This item includes looking at all layers of Simulink model for possible color coding not reflected at a higher level, and includes looking at any intermediate SWC Design versions between the version being implemented and the version that was included as a subproject in the previous implementation. | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: Synergy version number of the file being reviewed. (Version number that Synergy displays on the checked out or unmodified file in the working project) | |||||||||||||||
| Intended Use: For SWC Designs, list the Synergy baseline number (just the number part of the Synergy baseline name) of the SWC Design baseline being implemented. E.g., for SF001A_Assi_Design_1.3.1, this field would say "1.3.1" | |||||||||||||||
| Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s). | |||||||||||||||
| Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). | |||||||||||||||
| Intended Use: list version/revision of latest released Software Design and Coding Standards document. | |||||||||||||||
| Davinci Files | |||||||||||||||
| Intended Use: Identify if previous version was compared and only the expected change(s) was present. This is for text files only, not binary or GUIs | |||||||||||||||
| Polyspace | |||||||||||||||
| eg. 2013b | |||||||||||||||
| Integration manual | |||||||||||||||
| Intended Use: Identify which file is being reviewed | |||||||||||||||
| Intended Use: Identify which version of the integration manual has been reviewed. | |||||||||||||||
| Synergy | |||||||||||||||
| Refer to EA4 Common Naming Conventions document, section “Synergy Baseline Names for core components” | |||||||||||||||
| The following subprojects should be included for all component implementations: • AR200A_ArSuprt_Impl • AR201A_ArCplrSuprt_Impl • TL101A_CptRteGen • TL103A_CplrSuprt • TL109A_SwcSuprt • Corresponding _Design project used for the implementation The following subprojects should be included as needed by each component: • AR10xx_Nxtr*_Impl library components as needed by each component • AR202x_MicroCtrlrSuprt_Impl as needed (for register header files for components making direct register access)[add notes about when to add a stub header file] • Xx999x_xxxxGlbPrm_Impl as needed by each component • TL105A_Artt for components with generated content The following should NOT be included as subprojects: • TL107x_DavinciSuprt (aka StdDef) • TL100A_QACSuprt (QAC subproject was previously included but should be removed going forward) • Any other component (not mentioned anywhere above) whose .h file is needed. For these components, a “stub” .h file should be created, containing only the multiple include protection and the definitions and function prototypes actually needed by the component with the #include, and placed in the “including” component’s local\include folder. | |||||||||||||||
| misc in Summary sheet | |||||||||||||||
| (integrator, designer, unit test coordinator, etc.) | |||||||||||||||
| For a new component, use number of lines in all source files reviewed, including files in the src and include folders and any generated cfg.h and cfg.c files. For a changed component, try to add up how many lines, including comments and blank lines, were in the changed areas that were reviewed. Not just the actual changed lines, but the number of lines in the blocks of code you had to look at to review the change. | |||||||||||||||
| add up the number of ports, number of PIM variables, number if IRVs, number of runnables, number of NVM blocks in the component (all of them for review of a new component, the new and modified ones for review of a change) | |||||||||||||||
| add the number of pages in the MDD and integration manual for a new component; for a modified component, count the number of pages that contained a change. | |||||||||||||||
| Reviewer | Required attendance for this type of change | Review spreadsheet tab(s) | |||||||||||||
| Component group peer | All | All | |||||||||||||
| Component owner and/or SWC Design author | *Initial creation of any new component *Simulink model changes (any change to the model other than just updating the change log) | Source | |||||||||||||
| Integrator and/or SW lead of first program planning to use the component | *Initial creation of any new component *new or changed NVM blocks, NVM datatypes, or NVM usage (added or removed or changed NVM API calls in any runnable) *Major rev (X changed in the X.Y.X design baseline number; means there was a component interface change) *new or changed config params *all MM component changes | Davinci files, Integration manual, source for NVM changes and for all MM component changes. | |||||||||||||
| Unit test coordinator | Fixes for coverage issues | Source | |||||||||||||
| SQA | None | None | |||||||||||||
| For each reviewer category listed on each tab, there should either be • the name of the reviewer who attended or • a comment indicating o why that reviewer was not required for this change or o who approved holding the review without that required reviewer (approval must be from the software manager or a software supervisor) | |||||||||||||||
Sheet 4: Version History
| File Version History | ||||||
| Version | Description | Author(s) | Revision Date | Approved By | Approved Date | Status | 
| Draft/ Released | ||||||
| Template Version History | ||||||
| Version | Description | Author(s) | Revision Date | Approved By | Approved Date | Status | 
| 1.0 | Initial Version | SW Engineering team | 24-May-15 | NA | NA | Released | 
| 1.01 | Changed name to be EA4 specific | SW Engineering team | 25-Jun-15 | NA | NA | Released | 
| 1.02 | Modified Summary Sheet General Guidelines, Clarified wording on first item in Synergy project sheet. | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.02 | Made corrections and clarifications to Source Code check list. | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.02 | updated Davinci, MDD, and Polyspace/QAC tabs | SW Engineering team | 30-Jul-15 | NA | NA | Released | 
| 1.03 | Aligned to portal version guidelines | Umesh Sambhari | 21-Nov-17 | NA | NA | Released | 
| 2.00 | Summary sheet template: Changed title to indicate Implementation Peer Review Corrected and/or clarified mouse hover comments, added instructions, renamed some fields. Changed the default setting to "No" on the items reviewed | SW Engineering team | 29-Nov-17 | Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar | NA | Released | 
| Source code template: Removed hyperlink for naming conventions, corrected name of naming conventions document, added version field for naming conventions document. Changed item about requirements tags to reflect that they should be removed Added clarification that all combinations of conditionally compiled code must be checked Item about accurately implementing SWC Design is modified and a new item added, both to clarify where to look when determining needed changes. Added point for version of common naming conventions Reworded multiple items for clarity | SW Engineering team | 29-Nov-17 | ||||
| Synergy project template: added items for file/folder structure added point on .gpj file in tools folder | SW Engineering team | 29-Nov-17 | ||||
| Davinci files template: Clarified the StdDef item Added new item for OBSOLETE Clarified item on datadict.m comparison Removed the references to .m file helper tool Updated to reflect that all component should now use only implementation data types Added points on PIMs and NVMs | SW Engineering team | 29-Nov-17 | ||||
| All template tabs: Added/clarified/removed mouse hover comments. Updated Review Board section Removed the gridlines from all tabs Updated titles to say "Nexteer SWC Implementation Peer Review" Changed all occurences of "FDD" to "SWC Design" | SW Engineering team | 29-Nov-17 | ||||
| 2.01 | Added a help tab and appropriate links Added field on Summary sheet to report hours spent and content reviewed Changed wording in an item in Polyspace tab and Source code tab | SW Engineering team | 21-Feb-18 | Lonnie Newton, Steven Horwath, Kevin Smith, Lucas Wendling, Vinod Shankar | 21-Feb-18 | Released | 

7.2 - help
25.5. IDLE¶
Source code: Lib/idlelib/
IDLE is Python’s Integrated Development and Learning Environment.
IDLE has the following features:
- coded in 100% pure Python, using the tkinterGUI toolkit
- cross-platform: works mostly the same on Windows, Unix, and Mac OS X
- Python shell window (interactive interpreter) with colorizing of code input, output, and error messages
- multi-window text editor with multiple undo, Python colorizing, smart indent, call tips, auto completion, and other features
- search within any window, replace within editor windows, and search through multiple files (grep)
- debugger with persistent breakpoints, stepping, and viewing of global and local namespaces
- configuration, browsers, and other dialogs
25.5.3. Startup and code execution¶
Upon startup with the -s option, IDLE will execute the file referenced by
the environment variables IDLESTARTUP or PYTHONSTARTUP.
IDLE first checks for IDLESTARTUP; if IDLESTARTUP is present the file
referenced is run. If IDLESTARTUP is not present, IDLE checks for
PYTHONSTARTUP. Files referenced by these environment variables are
convenient places to store functions that are used frequently from the IDLE
shell, or for executing import statements to import common modules.
In addition, Tk also loads a startup file if it is present. Note that the
Tk file is loaded unconditionally. This additional file is .Idle.py and is
looked for in the user’s home directory. Statements in this file will be
executed in the Tk namespace, so this file is not useful for importing
functions to be used from IDLE’s Python shell.
25.5.3.1. Command line usage¶
idle.py [-c command] [-d] [-e] [-h] [-i] [-r file] [-s] [-t title] [-] [arg] ...
-c command  run command in the shell window
-d          enable debugger and open shell window
-e          open editor window
-h          print help message with legal combinations and exit
-i          open shell window
-r file     run file in shell window
-s          run $IDLESTARTUP or $PYTHONSTARTUP first, in shell window
-t title    set title of shell window
-           run stdin in shell (- must be last option before args)
If there are arguments:
- If -,-c, orris used, all arguments are placed insys.argv[1:...]andsys.argv[0]is set to'','-c', or'-r'. No editor window is opened, even if that is the default set in the Options dialog.
- Otherwise, arguments are files opened for editing and
sys.argvreflects the arguments passed to IDLE itself.
25.5.3.2. Startup failure¶
IDLE uses a socket to communicate between the IDLE GUI process and the user
code execution process. A connection must be established whenever the Shell
starts or restarts. (The latter is indicated by a divider line that says
‘RESTART’). If the user process fails to connect to the GUI process, it
displays a Tk error box with a ‘cannot connect’ message that directs the
user here. It then exits.
A common cause of failure is a user-written file with the same name as a standard library module, such as random.py and tkinter.py. When such a file is located in the same directory as a file that is about to be run, IDLE cannot import the stdlib file. The current fix is to rename the user file.
Though less common than in the past, an antivirus or firewall program may stop the connection. If the program cannot be taught to allow the connection, then it must be turned off for IDLE to work. It is safe to allow this internal connection because no data is visible on external ports. A similar problem is a network mis-configuration that blocks connections.
Python installation issues occasionally stop IDLE: multiple versions can clash, or a single installation might need admin access. If one undo the clash, or cannot or does not want to run as admin, it might be easiest to completely remove Python and start over.
A zombie pythonw.exe process could be a problem. On Windows, use Task Manager to detect and stop one. Sometimes a restart initiated by a program crash or Keyboard Interrupt (control-C) may fail to connect. Dismissing the error box or Restart Shell on the Shell menu may fix a temporary problem.
When IDLE first starts, it attempts to read user configuration files in ~/.idlerc/ (~ is one’s home directory). If there is a problem, an error message should be displayed. Leaving aside random disk glitches, this can be prevented by never editing the files by hand, using the configuration dialog, under Options, instead Options. Once it happens, the solution may be to delete one or more of the configuration files.
If IDLE quits with no message, and it was not started from a console, try
starting from a console (python -m idlelib) and see if a message appears.
25.5.3.3. IDLE-console differences¶
With rare exceptions, the result of executing Python code with IDLE is
intended to be the same as executing the same code in a console window.
However, the different interface and operation occasionally affect
visible results. For instance, sys.modules starts with more entries.
IDLE also replaces sys.stdin, sys.stdout, and sys.stderr with
objects that get input from and send output to the Shell window.
When Shell has the focus, it controls the keyboard and screen. This is
normally transparent, but functions that directly access the keyboard
and screen will not work. If sys is reset with importlib.reload(sys),
IDLE’s changes are lost and things like input, raw_input, and
print will not work correctly.
With IDLE’s Shell, one enters, edits, and recalls complete statements.
Some consoles only work with a single physical line at a time. IDLE uses
exec to run each statement. As a result, '__builtins__' is always
defined for each statement.
25.5.3.4. Developing tkinter applications¶
IDLE is intentionally different from standard Python in order to
facilitate development of tkinter programs. Enter import tkinter as tk;
root = tk.Tk() in standard Python and nothing appears. Enter the same
in IDLE and a tk window appears. In standard Python, one must also enter
root.update() to see the window. IDLE does the equivalent in the
background, about 20 times a second, which is about every 50 milleseconds.
Next enter b = tk.Button(root, text='button'); b.pack(). Again,
nothing visibly changes in standard Python until one enters root.update().
Most tkinter programs run root.mainloop(), which usually does not
return until the tk app is destroyed. If the program is run with
python -i or from an IDLE editor, a >>> shell prompt does not
appear until mainloop() returns, at which time there is nothing left
to interact with.
When running a tkinter program from an IDLE editor, one can comment out the mainloop call. One then gets a shell prompt immediately and can interact with the live application. One just has to remember to re-enable the mainloop call when running in standard Python.
25.5.3.5. Running without a subprocess¶
By default, IDLE executes user code in a separate subprocess via a socket, which uses the internal loopback interface. This connection is not externally visible and no data is sent to or received from the Internet. If firewall software complains anyway, you can ignore it.
If the attempt to make the socket connection fails, Idle will notify you. Such failures are sometimes transient, but if persistent, the problem may be either a firewall blocking the connection or misconfiguration of a particular system. Until the problem is fixed, one can run Idle with the -n command line switch.
If IDLE is started with the -n command line switch it will run in a single process and will not create the subprocess which runs the RPC Python execution server. This can be useful if Python cannot create the subprocess or the RPC socket interface on your platform. However, in this mode user code is not isolated from IDLE itself. Also, the environment is not restarted when Run/Run Module (F5) is selected. If your code has been modified, you must reload() the affected modules and re-import any specific items (e.g. from foo import baz) if the changes are to take effect. For these reasons, it is preferable to run IDLE with the default subprocess if at all possible.
Deprecated since version 3.4.
25.5.4. Help and preferences¶
25.5.4.1. Additional help sources¶
IDLE includes a help menu entry called “Python Docs” that will open the extensive sources of help, including tutorials, available at docs.python.org. Selected URLs can be added or removed from the help menu at any time using the Configure IDLE dialog. See the IDLE help option in the help menu of IDLE for more information.
25.5.4.2. Setting preferences¶
The font preferences, highlighting, keys, and general preferences can be changed via Configure IDLE on the Option menu. Keys can be user defined; IDLE ships with four built-in key sets. In addition, a user can create a custom key set in the Configure IDLE dialog under the keys tab.
25.5.4.3. Extensions¶
IDLE contains an extension facility. Preferences for extensions can be changed with the Extensions tab of the preferences dialog. See the beginning of config-extensions.def in the idlelib directory for further information. The only current default extension is zzdummy, an example also used for testing.
7.3 - sgml_input
| 
 | 
 | 
| Flotas (max. 9) | |||||||
| Num. | Misin | Cantidad | Comienzo | Salida | Objetivo | Llegada | Orden | 
|---|---|---|---|---|---|---|---|
| 1 | Espionaje (F) | 3 | [2:250:6] | Wed Aug 9 18:00:02 | [2:242:5] | Wed Aug 9 18:01:02 | |
| 2 | Espionaje (V) | 3 | [2:250:6] | Wed Aug 9 17:59:55 | [2:242:1] | Wed Aug 9 18:01:55 | |
7.4 - test_difflib_expect
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
| 42 | 123 | 42 | 123 | ||
| 43 | 123 | 43 | 123 | ||
| 44 | 123 | 44 | 123 | ||
| 45 | 123 | 45 | 123 | ||
| Legends | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 
 | 
 | |||||||||
Context (first diff within numlines=5(default))
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
Context (first diff after numlines=5(default))
| from | to | ||||
|---|---|---|---|---|---|
| 7 | 456 | 7 | 456 | ||
| 8 | 456 | 8 | 456 | ||
| 9 | 456 | 9 | 456 | ||
| 10 | 456 | 10 | 456 | ||
| 11 | 11 | ||||
| n | 12 | 1. Beautiful is beTTer than ugly. | n | 12 | 1. Beautiful is better than ugly. | 
| 13 | 2. Explicit is better than implicit. | ||||
| 14 | 3. Simple is better than complex. | 13 | 3. Simple is better than complex. | ||
| 15 | 4. Complex is better than complicated. | 14 | 4. Complicated is better than complex. | ||
| 15 | 5. Flat is better than nested. | ||||
| 16 | 123 | 16 | 123 | ||
| 17 | 123 | 17 | 123 | ||
| 18 | 123 | 18 | 123 | ||
| 19 | 123 | 19 | 123 | ||
| 20 | 123 | 20 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 26 | ||||
| n | 27 | 1. Beautiful is beTTer than ugly. | n | 27 | 1. Beautiful is better than ugly. | 
| 28 | 2. Explicit is better than implicit. | ||||
| 29 | 3. Simple is better than complex. | 28 | 3. Simple is better than complex. | ||
| 30 | 4. Complex is better than complicated. | 29 | 4. Complicated is better than complex. | ||
| 30 | 5. Flat is better than nested. | ||||
| 31 | 123 | 31 | 123 | ||
| 32 | 123 | 32 | 123 | ||
| 33 | 123 | 33 | 123 | ||
| 34 | 123 | 34 | 123 | ||
| 35 | 123 | 35 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 41 | ||||
| t | 42 | 1. Beautiful is beTTer than ugly. | t | 42 | 1. Beautiful is better than ugly. | 
| 43 | 2. Explicit is better than implicit. | ||||
| 44 | 3. Simple is better than complex. | 43 | 3. Simple is better than complex. | ||
| 45 | 4. Complex is better than complicated. | 44 | 4. Complicated is better than complex. | ||
| 45 | 5. Flat is better than nested. | ||||
| 46 | 123 | 46 | 123 | ||
| 47 | 123 | 47 | 123 | ||
| 48 | 123 | 48 | 123 | ||
| 49 | 123 | 49 | 123 | ||
| 50 | 123 | 50 | 123 | ||
Context (numlines=6)
| from | to | ||||
|---|---|---|---|---|---|
| f | 1 | f | 1 | ||
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
Context (numlines=0)
| from | to | ||||
|---|---|---|---|---|---|
| n | 2 | 1. Beautiful is beTTer than ugly. | n | 2 | 1. Beautiful is better than ugly. | 
| 3 | 2. Explicit is better than implicit. | ||||
| 4 | 3. Simple is better than complex. | 3 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 4 | 4. Complicated is better than complex. | ||
| 5 | 5. Flat is better than nested. | ||||
| n | 17 | 1. Beautiful is beTTer than ugly. | n | 17 | 1. Beautiful is better than ugly. | 
| 18 | 2. Explicit is better than implicit. | ||||
| 19 | 3. Simple is better than complex. | 18 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 19 | 4. Complicated is better than complex. | ||
| 20 | 5. Flat is better than nested. | ||||
| t | 32 | 1. Beautiful is beTTer than ugly. | t | 32 | 1. Beautiful is better than ugly. | 
| 33 | 2. Explicit is better than implicit. | ||||
| 34 | 3. Simple is better than complex. | 33 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 34 | 4. Complicated is better than complex. | ||
| 35 | 5. Flat is better than nested. | ||||
Same Context
| from | to | ||||
|---|---|---|---|---|---|
| t | No Differences Found | t | No Differences Found | ||
Same Full
| from | to | ||||
|---|---|---|---|---|---|
| t | 1 | t | 1 | ||
| 2 | 1. Beautiful is beTTer than ugly. | 2 | 1. Beautiful is beTTer than ugly. | ||
| 3 | 2. Explicit is better than implicit. | 3 | 2. Explicit is better than implicit. | ||
| 4 | 3. Simple is better than complex. | 4 | 3. Simple is better than complex. | ||
| 5 | 4. Complex is better than complicated. | 5 | 4. Complex is better than complicated. | ||
| 6 | 123 | 6 | 123 | ||
| 7 | 123 | 7 | 123 | ||
| 8 | 123 | 8 | 123 | ||
| 9 | 123 | 9 | 123 | ||
| 10 | 123 | 10 | 123 | ||
| 11 | 123 | 11 | 123 | ||
| 12 | 123 | 12 | 123 | ||
| 13 | 123 | 13 | 123 | ||
| 14 | 123 | 14 | 123 | ||
| 15 | 123 | 15 | 123 | ||
| 16 | 16 | ||||
| 17 | 1. Beautiful is beTTer than ugly. | 17 | 1. Beautiful is beTTer than ugly. | ||
| 18 | 2. Explicit is better than implicit. | 18 | 2. Explicit is better than implicit. | ||
| 19 | 3. Simple is better than complex. | 19 | 3. Simple is better than complex. | ||
| 20 | 4. Complex is better than complicated. | 20 | 4. Complex is better than complicated. | ||
| 21 | 123 | 21 | 123 | ||
| 22 | 123 | 22 | 123 | ||
| 23 | 123 | 23 | 123 | ||
| 24 | 123 | 24 | 123 | ||
| 25 | 123 | 25 | 123 | ||
| 26 | 123 | 26 | 123 | ||
| 27 | 123 | 27 | 123 | ||
| 28 | 123 | 28 | 123 | ||
| 29 | 123 | 29 | 123 | ||
| 30 | 123 | 30 | 123 | ||
| 31 | 31 | ||||
| 32 | 1. Beautiful is beTTer than ugly. | 32 | 1. Beautiful is beTTer than ugly. | ||
| 33 | 2. Explicit is better than implicit. | 33 | 2. Explicit is better than implicit. | ||
| 34 | 3. Simple is better than complex. | 34 | 3. Simple is better than complex. | ||
| 35 | 4. Complex is better than complicated. | 35 | 4. Complex is better than complicated. | ||
| 36 | 123 | 36 | 123 | ||
| 37 | 123 | 37 | 123 | ||
| 38 | 123 | 38 | 123 | ||
| 39 | 123 | 39 | 123 | ||
| 40 | 123 | 40 | 123 | ||
| 41 | 123 | 41 | 123 | ||
| 42 | 123 | 42 | 123 | ||
| 43 | 123 | 43 | 123 | ||
| 44 | 123 | 44 | 123 | ||
| 45 | 123 | 45 | 123 | ||
Empty Context
| from | to | ||||
|---|---|---|---|---|---|
| t | No Differences Found | t | No Differences Found | ||
Empty Full
| from | to | ||||
|---|---|---|---|---|---|
| t | Empty File | t | Empty File | ||
tabsize=2
| f | 1 | f | 1 | ||
| t | 2 | Line 1: preceded by from:[tt] to:[ssss] | t | 2 | Line 1: preceded by from:[tt] to:[ssss] | 
| 3 | Line 2: preceded by from:[sstt] to:[sssst] | 3 | Line 2: preceded by from:[sstt] to:[sssst] | ||
| 4 | Line 3: preceded by from:[sstst] to:[ssssss] | 4 | Line 3: preceded by from:[sstst] to:[ssssss] | ||
| 5 | Line 4: has from:[sst] to:[sss] after : | 5 | Line 4: has from:[sst] to:[sss] after : | ||
| 6 | Line 5: has from:[t] to:[ss] at end | 6 | Line 5: has from:[t] to:[ss] at end | 
tabsize=default
| f | 1 | f | 1 | ||
| t | 2 | Line 1: preceded by from:[tt] to:[ssss] | t | 2 | Line 1: preceded by from:[tt] to:[ssss] | 
| 3 | Line 2: preceded by from:[sstt] to:[sssst] | 3 | Line 2: preceded by from:[sstt] to:[sssst] | ||
| 4 | Line 3: preceded by from:[sstst] to:[ssssss] | 4 | Line 3: preceded by from:[sstst] to:[ssssss] | ||
| 5 | Line 4: has from:[sst] to:[sss] after : | 5 | Line 4: has from:[sst] to:[sss] after : | ||
| 6 | Line 5: has from:[t] to:[ss] at end | 6 | Line 5: has from:[t] to:[ss] at end | 
Context (wrapcolumn=14,numlines=0)
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | 
wrapcolumn=14,splitlines()
| f | 1 | line 0 | f | 1 | line 0 | 
| 2 | 12345678901234 | 2 | 12345678901234 | ||
| > | 56789012345689 | > | 56789012345689 | ||
| > | 012345 | > | 012345 | ||
| 3 | line 1 | 3 | line 1 | ||
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| 5 | line 3 | 5 | line 3 | ||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| 9 | line 7 | 9 | line 7 | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| 11 | line 9 | 11 | line 9 | ||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | ||
| 16 | the end | 16 | the end | 
wrapcolumn=14,splitlines(True)
| f | 1 | line 0 | f | 1 | line 0 | 
| 2 | 12345678901234 | 2 | 12345678901234 | ||
| > | 56789012345689 | > | 56789012345689 | ||
| > | 012345 | > | 012345 | ||
| 3 | line 1 | 3 | line 1 | ||
| n | 4 | line 2 | n | 4 | line 2 adde | 
| > | d | ||||
| 5 | line 3 | 5 | line 3 | ||
| n | 6 | line 4 chang | n | 6 | line 4 chanG | 
| > | ed | > | Ed | ||
| 7 | line 5 chang | 7 | line 5a chanG | ||
| > | ed | > | ed | ||
| 8 | line 6 chang | 8 | line 6a chang | ||
| > | ed | > | Ed | ||
| 9 | line 7 | 9 | line 7 | ||
| n | 10 | line 8 subtra | n | 10 | line 8 | 
| > | cted | ||||
| 11 | line 9 | 11 | line 9 | ||
| t | 12 | 12345678901234 | t | 12 | 1234567890 | 
| > | 56789012345689 | ||||
| > | 012345 | ||||
| 13 | short line | 13 | another long l | ||
| > | ine that needs | ||||
| > | to be wrapped | ||||
| 14 | just fits in!! | 14 | just fitS in!! | ||
| 15 | just fits in t | 15 | just fits in t | ||
| > | wo lines yup!! | > | wo lineS yup!! | ||
| 16 | the end | 16 | the end | 
8.1 - SwcSuprt_Usage
| Version | Date | Author | Description | 
|---|---|---|---|
| 1 | 01-Dec-2016 | Owen Tosh | Initial version | 
| 2 | 07-Dec-2016 | Owen Tosh | Added Polyspace report generation | 
| 3 | 30-Mar-2017 | Matt Leser | Added Sandbox Project Creation | 
| 4 | 18-May-2017 | Matt Leser | Expanded on descriptions, Updated Graph to show where Sandbox Project is located | 
Table of Contents
File and Directory Structure 8
Introduction
SwcSuprt is a component support script for EA4 component development. It automates many redundant tasks, and is useful to easily update a component to the latest standards.
Both GUI and command-line interfaces are supported. If this script is run with both a path to a component and a command, the script continues running in the command line. Otherwise, the GUI is initialized.
Dependencies
This tool requires the TL112A_Python component. This component contains the Nexteer Python library nxtr.py, which is required by this tool (a vanilla Python environment will not contain this library).
Running the Tool
Launch.bat
In the tools directory, running Launch.bat will load the tool directly with no arguments. The tool prompts the user with the main menu, which can be used to create a new component or select an existing component. Once this is done, the user is prompted with the component menu.
SWCSupport.bat
Once the tool is integrated with a component, it can be launched with SWCSupport.bat, located in the component’s tools directory. This will immediately launch the component menu.
Command Line Usage
The expected command line format is as follows:
swcsuprt.py ["/path/to/component" [command]]
If no arguments are provided, the tool will present the main menu. If run with a single argument, the tool will open the component menu for the component at the path provided. The path may be relative or absolute.
If run with two arguments, the tool will run in a non-interactive command line format. command may be one of the following:
- initialize – create basic directories if they don't already exist 
- migrate – perform component migration to latest directory format. Also runs: - generate_greenhills 
- generate_davinci 
- generate_integration_files 
- generate_generation_script 
 
- generate_greenhills – generate Green Hills project file 
- generate_davinci – generate DaVinci component files 
- generate_integration_files – generate integration files 
- generate_generation_script – generate generation batch script, or remove it if not necessary 
- generate_sandbox – generate sandbox project 
- generate_local_headers – generate local header files from Configurator 
- generate_polyspace_files – generate Polyspace project files and stubs 
- unzip_poly space – unzip Polyspace archives 
- open_bugfinder – open Polyspace Bug Finder project 
- open_codeprover – open Polyspace Code Prover project 
- zip_polyspace – zip current Polyspace results into archives 
See the description of the functions in the component menu for more details on each command.
The Main Menu

Click New Component to create a folder template for a new component. The tool will prompt for a full component name and parent directory, and then present the component menu for the newly created component. The new component will only contain the basic folder structure, and the SWCSupport.bat script.
Click Select Existing to open the component menu for an existing component. The tool will prompt for the main component directory. If the selected directory is missing the standard component subfolders (e.g. autosar, src, include), the tool will display a warning.
Click ? to open this usage document.
Click Quit to close the tool.
The Component Menu

The main menu contains five sections:
Component
The component short name is shown here.
If the component appears to be of an older format (e.g. contains a tools/contract directory), this section will also contain an additional button. Click Migrate to automatically update this component to the latest format, moving files as needed. Note that this will also run all commands in the Create/Update section.
Create/Update
Click Green Hills to generate the Green Hills project file (.gpj).
Click DaVinci to generate the DaVinci Configurator project files. This includes the DaVinci Project file (.dpa) and some files in the tools/local/autosar directory. Note that if a .bswmd.arxml file is added to the autosar folder, this function must be run in order to include it in the component configuration.
Click Integration Files to generate files for integration. This feature checks for any .bswmd.arxml files in the autosar directory, then creates an integration script in the tools/integrate folder. If no .bswmd.arxml files are found, no integration script is needed and it is removed.
Click Generation Script to generate the batch script used by Configurator when generating configuration files from ARTT text template files. This feature checks for any template files (.tt) in the tools/template directory, and creates a generation script if found. Otherwise, the generation script is removed.
Click Sandbox Project to generate the sandbox project used from the Green Hills project file. (.gpj). The project file will open as well even if no update/creation took place. The sandbox is an area used to test if component level source codes compile. This will also generate the .d, .dbo, and .o files in a folder called SandboxOutput that is located on the same level as the components.
Davinci
Click Generate to generate the RTE files, contract header files, and any configurable files of the component for local compilation testing and static analysis. If an error occurs, log files may exist in the tools directory, as well as the tools/local/generate directory.
Polyspace
Click Generate Files to generate all project and related files to the tools/Polyspace directory. This function checks for all source files and include directories, adding them to the Polyspace projects. It also looks for a corresponding design component in the component’s parent directory. If not automatically found, the user is prompted to locate it manually or proceed without using a data dictionary. Note that not using a data dictionary causes many orange errors in Code Prover. It is recommended to run this function before analysis is performed.
Click Unzip Results to decompress any saved results from previous analyses. Previous results are stored in the tools/Polyspace/Saved directory.
Click Open Bug Finder to open the Bug Finder Polyspace project.
Click Open Code Prover to open the Code Prover Polyspace project.
Click Create Reports to generate XML reports from the Bug Finder and Code Prover results. These reports may be used in the future to gather information at the request of the customer. Currently, they will be stored in Synergy to prepare for potential use.
Click Zip Results to delete backup comment folders and archive the current results to the tools/Polyspace/Saved directory.
Other Buttons
Click ? to open this usage document.
Click Quit to close the tool.
File and Directory Structure
The following directories exist in every software component:
autosar – contains all Developer/Configurator files
doc – documentation
generate – all generated source and header files (used in the integration project)
include – component header files
src – component source files
tools – contains the component DaVinci project file, the Green Hills Project file, and a script to launch the SwcSuprt tool
tools/integrate – all integration-related files
tools/local – all files used in local component development, but not used at the integration project level. This contains any stubs required for static analysis, as well as configurator files used to create a local environment. Each directory in this path resembles the base directory structure (e.g. autosar, generate, include, src).
tools/Polyspace – Polyspace Bug Finder and Code Prover project files, along with project-related files. Also contains the archived results from previous analyses.
tools/template – any files involved in generation from text templates at both the component and integration project level
8.2 - TL109A_SwcSuprt Peer Review Checklist
Overview
Summary SheetSynergy Project
Sheet 1: Summary Sheet


















