Up- and Downwards-Compatibility

[tbrandenburg]

Hello cogu,

and greets to Sweden.

Currently I am loading real-world example and came across several NotImplementedErrors, e.g. for:

• DIAGNOSTIC-EVENT-NEEDS
• SUPERVISED-ENTITY-NEEDS
• BSW-MGR-NEEDS
• CATEGORY
• ECU-EXTRACT-VERSION
• etc.

Then I realized that I was parsing a AUTOSAR_00049 file instead of AUTOSAR_4-2-2

My questions are:

• How have you planned to support several versions of XSDs in one tool? Should the parser only expect the items defined in XSD or should it be in "umbrella" mode -> so take what is known. Both strategies seem to be not supported yet (at least parser seems to be quite sensible on anything unknown and parsing is workspace version independent)
• I am currently wondering if I should create a fork for introducing some AUTOSAR_00049 measures or make the tool more upwards compatible and less strict or if that strategy ever gets the chance of a pull request by creating a branch here. What is your suggestion?

Best regards, Tom

[cogu]

Hello @tbrandenburg,

Unfortunately I have very little time these days to do any open source development but I will try to answer as best as I can.

The Python package will not officially support upgrading or downgrading between versions. It will parse the ARXML using the version it sees in the version line (where the namespace and schema stuff is mentioned) and then it's able to save it back again to ARXML using the same version.

AUTOSAR 3

There seems to be users of this package still on AUTOSAR 3 so there's a version check that makes a hard fork between version 3 and version 4 parsing but I'm sure you have noticed in the code already.

AUTOSAR 4+

It's correct that the Python package is still on AUTOSAR 4.2. That's the version we're still using for the commercial projects I support. The following part I haven't clearly worked out yet and this is just my idea of how it might work in the future. If we disregard AUTOSAR 4.3, and 4.4 for the moment and just focus on newer AUTOSAR versions, then the release number should be available under the Workspace.release property. This is an integer that should match the schema file it saw earlier during the parsing, in your case, the ws.release property should come out as 49. Whenever there's a difference between AUTOSAR releases and a specific feature only exists in a newer versions, the idea is to place if-statements in the parser code that can take different actions. For example, let's say a feature was introduced in R46 and it's still available in R49.

if ws.release >= 46:
    # Do something specific for R46 and higher
else:
   # Do something for other versions

Be wary that the ws.release property might come out as None for lower AUTOSAR versions (between 4.0 and 4.4) so you might also want to do a if ws.release is not None check just to be safe. I might fix this gap in the future if I can find a suitable solution.

You're welcome to create a fork and try this strategy out. Hope the answer helped.

[cogu]

Release v0.5.0+ supports schema version 49 but those specific elements you mention are not yet implemented. Most of them are planned for v0.5.6.