Model Merge Behavior on Project Load
When a DaVinci Project is loaded, the DaVinci Configurator Classic loads the referenced ARXML files of the project setting files in a specific order. The AUTOSAR elements in these files are merged into the in-memory model in this order. If the same element is defined in multiple files, especially when the elements are defined as AUTOSAR splitable, these elements can be conflicting.
The DaVinci Configurator Classic identifies and reports these conflicts. Some conflicts can be automatically resolved by the tool if the user activates the option, described in How to Activate the Best-Effort Automatic Conflict Resolution. Other conflicts may need manual resolution.
The following sections explain:
What Priority Are ARXML Files Assigned When a Conflict Happens
The DaVinci Configurator Classic uses a priority based model merge to load the content of ARXML files. The ARXML files, referenced in the project setting files, are assigned a priority based on their type or folder structure. This priority has a direct influence on why conflicts can arise and how they are resolved if possible.
Following table shows the detailed priority assignment of the different source types.
| Priority | Source Type | Referenced in |
|---|---|---|
1 |
Platform Types |
|
2 |
BSWMD |
* |
3 |
DaVinci Developer Classic Workspace |
|
4 |
IFP Recommended EcuC |
|
5 |
Application Components |
|
6 |
Timing Extension |
|
7 |
IFP EcuC & IFP Diagnostic EcuC |
|
8 |
Definition Restriction |
|
9 |
IFP HarmonizedExtract EcuC |
|
10 |
External EcuC File |
|
11 |
Recommended User-Authored EcuC |
|
12 |
Software Components |
|
13 |
Internal Behavior |
|
14 |
Evaluated Variant Set |
|
15 |
Structured Extract |
|
16 |
User-Authored EcuC |
*: Files from the BSW Package are loaded automatically. The BSW Package is always provided to any DaVinci Configurator Classic task in the corresponding user interface and is not referenced by a project setting file.
Why Is the Priority Important
If two ARXML files define the same (identifiable) AUTOSAR element with different content, a merge conflict can arise on project load. The priorities of ARXML files define in ascending order, which file’s content should be prioritized in case of a conflict.
For manual conflict resolution by the user, it is important to understand the file source types that are conflicting. When in doubt, the priority assignment can help to understand why a specific conflict arises. The DaVinci Configurator Classic can also automatically resolve some conflicts based on the priority assignment, see How to Activate the Best-Effort Automatic Conflict Resolution.
|
A higher priority number means that the objects of these locations win in case of a conflict, if the automatic conflict resolution is activated. We recommend to recheck any automatic conflict resolutions before saving the project. For this the priorities help you by understanding why a specific value was chosen by the tool. |
For the automatic conflict resolution, the priority assignment is used to resolve differences automatically. If a merge conflict is found between the content of two files, the assigned priorities are considered to resolve and merge the values.
-
File AC.arxml (Application Components) defines an AUTOSAR element with short name "XInitCfg".
-
File SC.arxml (Software Components) also defines an AUTOSAR element with short name "XInitCfg".
Assuming both elements have the same AUTOSAR path, e.g. /Init/XInitCfg, and contain different attributes, a merge conflict arises on project load. On automatic merge the value from SC.arxml is chosen, as it has the higher priority (5 vs. 14).
|
The DaVinci Configurator Classic saves data into the ARXML files conflict-free. Any conflict that was resolved by the automatic conflict resolution will overwrite the content of corresponding ARXML files on the next triggered project save. Note that conflicts with read-only files are still possible, as these are not overwritten by the tool. |
How Are Directories Considered in the Priority Based Model Merge
The above priority assignment is defined for different types of ARXML files, which can be referenced in the ArxmlProjectContent.json as
-
dir (a single directory),
-
dirList (a list of directories),
-
fileList (a list of files) or
-
file (a single file).
All files inside a referenced directory inherit the priority of the directory type. Inside a directory, the next-level priority is determined by file names. For each single referenced directory, subfolders are also recursively searched for ARXML files and all found files for a directory reference are alphabetically sorted. If files or directories are referenced as a list in the settings file, the order of the list is considered instead.
folderX
|-- a.arxml
|-- folderY (Subfolder)
|-- z.arxml
|-- c.arxml
If there is a merge conflict between a.arxml and c.arxml, the value of a.arxml would be prioritized by the automatic conflict resolution.
Are Files Inside the DaVinci Developer Classic Workspace Affected by the Priority
No, files of the DaVinci Developer Classic Workspace are loaded as defined by the DaVinci Developer Classic. The in-model representation of the ARXML files is identically to the one in the DaVinci Developer Classic. The assigned priority for the DaVinci Developer Classic Workspace only holds in case of conflicts with other ARXML files for the DaVinci Configurator Classic.
How Are Conflicts of Non-Splitable Elements Handled
Some elements in AUTOSAR are not defined as splitable. This means these elements should only be defined once in all ARXML files. If such an element is nonetheless defined multiple times in different files, a conflict can still be introduced. The following sections explain how the DaVinci Configurator Classic behaves in such cases. See also: How to Activate the Best-Effort Automatic Conflict Resolution
Equal Duplicates of Non-Splitable Elements
If a non-splitable element is defined multiple times in different ARXML files and the values are identical, no problem is reported and the tool conveniently merges the values. The in-model representation will contain only one instance of these identical elements, as the element is non-splitable. The textural elements of both original files will not be deleted or changed on next DaVinci Project save.
Conflicting Duplicates of Non-Splitable Elements
If a non-splitable element is defined multiple times in different ARXML files and the values are conflicting, a conflict is reported to the user. Based on the type of conflict, it can or cannot be automatically resolved by the tool. See Which Model Merge Conflicts Can Arise to understand different types of error messages here and how to handle them.
Conflicting XML Attributes
Most conflicts in the XML attributes are also reported by the DaVinci Configurator Classic. If the automatic conflict resolution is activated, the XML conflicts are merged based on the priority of the files.
The only exception here are the S (checksum) and T (timestamp) attributes of any AUTOSAR element, which are not reported as conflicts, as these can be quite tedious to fix. A conflict between checksum or timestamp can also be automatically merged based on the priority of the files if the option is activated.
Which Non-Splitable Elements Are Always Auto-Resolved and Not Reported If Conflicting
Following conflicts in non-splitable AUTOSAR elements are ignored by the DaVinci Configurator Classic, if they arise, that are:
-
DocumentationBlock
-
MultiLanguageOverviewParagraph
-
MultiLanguageParagraph
-
MultiLanguagePlainText
-
MultiLanguageVerbatim
-
MultilanguageLongName
These elements are not defined as AUTOSAR splitable and should not be included in multiple files. If they are still duplicated and conflicting, the DaVinci Configurator Classic will always merge them based on the file priority and choose the value of the file with higher priority.
|
The tool always automatically merges the conflicts' values of above AUTOSAR elements, by choosing the value of the file with higher priority. This is a convenience feature as these values are not considered in the DaVinci Configurator Classic workflow. |
Which Model Merge Conflicts Can Arise
The DaVinci Configurator Classic differs between solvable and non-solvable conflicts. Solvable conflicts can be automatically resolved by the tool, if the user activates the option, described in How to Activate the Best-Effort Automatic Conflict Resolution. Non-solvable conflicts are always reported as errors by the tool. The following sections describe different types of conflicts that can arise on project load.
The general structure of a conflict message is as follows:
-
Information about automatic merge resolution (if applied), formatted by
[AUTOMATIC MERGE APPLIED] {{winning value}} from {{winning file}} -
Description of the conflict type and the conflicting element
-
The cause of the conflict, providing more details depending on the type
-
The files and their line and column numbers, denoting a section where the conflicting element or the parent elements are contained, formatted by
file: startLine[column] - endLine[column]
[AUTOMATIC MERGE APPLIED] "2" from Config/EcuConfig/Demo.ecuc.arxml Invalid model split detected for "/ActiveEcuC/CanIf/CanIfInitCfg/CHNL_b9109e7b[CanIfBufferSize]" (DefRef: /MICROSAR/CanIf/CanIfInitCfg/CanIfBufferCfg/CanIfBufferSize). Cause: The parameter is contained with different values (2 <-> 0). Contained in [ Output/Config/EcuConfig/Demo_IFP_recommended.arxml: 243[17] - 258[40] Config/EcuConfig/Demo.ecuc.arxml: 322[17] - 352[40] ]
|
The line and column information is based on a best-effort computation, which describes the position of the nearest Referrable parent element. The reported conflict may currently only find the first instance fitting the conflict criteria in a file. If you can find multiple instances of the conflicting element in one file, double-check all instances to find the correct one. The same holds for elements with variation points, which might be defined on higher parent elements. → The localization will improve in future versions. Feedback is appreciated. |
How to Manually Solve Conflict "Illegal File Split"
The conflict "Illegal File Split" is the most universal type of conflict that can arise on project load. It arises if an AUTOSAR element (splitable or non-splitable) is defined in multiple files, but the split is not valid.
| The "Illegal File Split" conflict is solvable by the automatic conflict resolution of the DaVinci Configurator Classic. |
How to fix this conflict manually:
-
Open the files that are reported for this conflict.
-
Compare all instances of the conflicting element in the files.
-
If the files are not auto-generated by any tool and one element instance can be deleted, check if any instance could be removed.
-
Alternatively, adapt the values to be equal if both files should keep the element.
-
-
Try to find the origin of the instances of the conflicting files and correct the source if possible.
| If the conflicting element has a unique name or value, you can also use the search functionality of your text editor to find all instances in a file. |
How to Manually Solve Conflict "Merging by Splitkey Failed"
The conflict "Merging by splitkey failed" arises if an AUTOSAR splitable element is defined multiple times in the ARXML files and the identification of the element is not unique but ambiguous. This problem typically arises if one file contains multiple instances of the same splitable element.
The AUTOSAR standard defines for each splitable element, how the splitkey is composed. Commonly used components of the splitkey are the short name or short label. For more information, see the AUTOSAR documentation about splitable elements. If the splitkey does not uniquely identify an element, the tool cannot decide which instance should be merged.
| This conflict is non-solvable and needs manual fixing. |
How to fix this conflict manually:
-
Open the files that are reported for this conflict.
-
Compare all instances of the conflicting element in the files.
-
Check if all variation points are correctly defined as intended and contain the corresponding short label.
-
Check if all instances of the conflicting element can be uniquely identified by the splitkey components.
-
Remove unnecessary instances of the conflicting element from your ARXML files.
-
How to Manually Solve Conflict "Missing Variation Point"
The conflict "Missing Variation Point" arises if an AUTOSAR splitable element is defined multiple times in the ARXML files and one instance is missing a (Post build) variation point definition. Variation points are used to define different variants of an AUTOSAR element. If one instance of a splitable element is missing the variation point definition, the tool cannot decide which instances should be merged.
| This conflict is non-solvable and needs manual fixing. |
How to fix this conflict manually:
-
Open the files that are reported for this conflict.
-
Compare all instances of the conflicting element in the files.
-
Check if all variation points are correctly defined as intended.
-
Copy or remove variation points to make all instances consistent.
| Variation points are hereditary. Check the parent elements for variation points as well. |
How to Manually Solve Conflict "Missing or Conflicting Short Labels in Variation Point"
The conflict "Missing or Conflicting Short Labels in Variation Point" arises if an AUTOSAR splitable element is defined multiple times in the ARXML files and the variation point differ in their short label definition. Variation points are used to define different variants of an AUTOSAR element. If one instance of a splitable element is missing a short label of a variation point definition, the tool cannot decide which instances should be merged.
| This conflict is non-solvable and needs manual fixing. |
How to fix this conflict manually:
-
Open the files that are reported for this conflict.
-
Compare all instances of the conflicting element in the files.
-
Check if all variation points are correctly defined with the same short labels and correct them.
| Variation points are hereditary. Check the parent elements for variation points as well. |
How to Activate the Best-Effort Automatic Conflict Resolution
The best-effort conflict resolution can be (de-)activated per project.
| If the project load still aborts with the automatic conflict resolution, then the project contains non-solvable conflicts. Resolve any reported conflicts with ERROR level manually. |
Activate the automatic conflict resolution by activating the setting in the project setting file General.json by activating following entry:
{
"allowMergeConflicts": true
}
|
The next DaVinci Project save action will write the automatically resolved values into the corresponding ARXML files. Check any automatic resolutions carefully before saving the project. Some CLI tasks of the DaVinci Configurator Classic might also trigger an automatic project save, therefore, it is not recommended to by-default activate the automatic conflict resolution for projects. |
How Does the Automatic Conflict Resolution Work
The best-effort conflict resolution can be activated to automatically resolve any solvable conflicts on project load. The logic considers the priority assignment of the different ARXML file types, explained in What Priority Are ARXML Files Assigned When a Conflict Happens. If a solvable conflict is found, the tool automatically merges the conflicting element by choosing the value of the file with higher priority. The resolved conflicts are listed in the SARIF report. How to Open the SARIF Report of Found Model Merge Conflicts
| If your project contains solvable and non-solvable conflicts, activate the automatic conflict resolution and reload the project, to resolve any other solvable problems first. Resolving the non-solvable problems manually will then be easier. Please note to still check the correctness of auto-resolved conflicts in the report. |
How to Open the SARIF Report of Found Model Merge Conflicts
When the DaVinci Configurator Classic finishes loading the ARXML files, a SARIF report file of the found Model Merge Conflicts is generated into the DaVinci Project in Output/Log/ProjectLoad/.
The tool provides a new report for each DaVinci Project load, even if the load is unsuccessful and aborted.
How to Interpret Line Numbers in the SARIF Report
A model merge conflict in the SARIF report contains the parsed location of the conflicting elements in the ARXML files. Currently, all line numbers and locations can only be computed for a Referrable based on the AUTOSAR short names. If the conflicting element is not a Referrable itself a parent Referrable is used. For the correct interpretation of the conflict the DaVinci Configurator Classic also provides the definition reference, value and XML name for the conflicting element.