when the dop-snref refer to another file.

[yangshengquan1026]

When the do-snref index in one file is referenced to another file, the program will not run.
test.zip

When loading ODX files, each ODX file's content is added to a master library, and in theory, the indexing should not be a problem. However, in practice, the indexing can only be done within the current file, and if the dop-snref is not within the file, the program will not be able to continue executing.

[andlaus]

your dataset has an issue: the parameter "DTCFU" which is part of the structure "DTCASVR_STRUCT" defined by ECU-SHARED-DATA layer "SD_UDS_Services" references a DOP called "Uint_IDENTICAL_8Hex" via SNREF which is not defined in that ECU-SHARED-DATA layer. The best way to fix that is to use an ODXLINK reference to the DOP (i.e., specify DOP-REF instead of DOP-SNREF in parameters)

[yangshengquan1026]

andlaus, thank you for your prompt reply! Yes, you are correct. My dop-snref will be queryable if it is defined in this file's query, but not if it is defined in another file. This is because the tool used by Softing to generate the test.pdx file works correctly, but the tool used by ODX Tools does not. I have tried modifying the old version of ODX Tools to fix this issue, but it worked only temporarily. It seems that ODX Tools stores all the fields of each file in a common dictionary, such as all the fields of diagservice in one dictionary, and all the fields of dop in another. I am not very familiar with Python, but I am trying to understand the underlying principles so that I can convert it to C/C++ or Rust. I have already generated classes for each file's parent node and multiple attribute nodes. However, this project is still quite large for personal research, and I will have to work on it gradually.

[andlaus]

My dop-snref will be queryable if it is defined in this file's query, but not if it is defined in another file

This might be a vagueness in the ODX standard: I believe that SNREFs must be resolvable in all contexts that occur in a given database (i.e., if there is a SNREF in an ECU-SHARED-DATA layer, it must be resolvable with just the data available in that layer). Since -- to my knowledge -- the specification makes no explicit statement about this, the softing tools might take a different approach (if they are heavily based on XPATH expressions, on-the-fly lookups might even be easier for them to implement). As said, using ODXLINK references (DOP-REF) avoids this issue...

[cmydd]

这个问题没有修复.SNREF必须提取到ecuvariant里面才不会出错 但是c++ 很好实现 python都是引用 动一个其他全部会改变

[yangshengquan1026]

My dop-snref will be queryable if it is defined in this file's query, but not if it is defined in another file

This might be a vagueness in the ODX standard: I believe that SNREFs must be resolvable in all contexts that occur in a given database (i.e., if there is a SNREF in an ECU-SHARED-DATA layer, it must be resolvable with just the data available in that layer). Since -- to my knowledge -- the specification makes no explicit statement about this, the softing tools might take a different approach (if they are heavily based on XPATH expressions, on-the-fly lookups might even be easier for them to implement). As said, using ODXLINK references (DOP-REF) avoids this issue...

thank you！

[yangshengquan1026]

这个问题没有修复.SNREF必须提取到ecuvariant里面才不会出错 但是c++ 很好实现 python都是引用 动一个其他全部会改变

有没有想法像他们这样搭建一个c++/rust版本的odxtools?

[cmydd]

c++实现完成了 他这个基本上是没问题的 只是snref会有问题 之前有做过 但是没有按照标准的iso 22901来实现. 现在在测试 有一些问题

[yangshengquan1026]

c++实现完成了 他这个基本上是没问题的 只是snref会有问题 之前有做过 但是没有按照标准的iso 22901来实现. 现在在测试 有一些问题

我看这个odxtools和那个java的都有了，但是现在就c++和rust的还比较欠缺。

[cmydd]

c++实现完成了 他这个基本上是没问题的 只是snref会有问题 之前有做过 但是没有按照标准的iso 22901来实现. 现在在测试 有一些问题

我看这个odxtools和那个java的都有了，但是现在就c++和rust的还比较欠缺。

请问 java的哪里有开源的呢