PDU container vs multiplexed: for ARXML

[jazi007]

Hello,

In canmatrix CAN-FD contained PDU are considered as multiplexed CAN-Frame.
I think this is not "true" for CAN FD with dynamic multi-PDU-to-frame mapping
For example in arxml format CONTAINER-I-PDU it's not a multiplexed frame but a dynamic mutlti-pdu container
(as reference AUTOSAR_SWS_IPDUMultiplexer.pdf section 7.2/7.3)

I saw that you have defined a Pdu class but it's only used for flexray as stated in the class comment.

so is it expected that canmatrix consider PDU container for CAN as multiplexed ? do we need to rework this part and make use of Pdu class even for CAN ? and in this case what will happen for conversion to other formats that doesn't support the dynamic pdus ?

I can help doing the change from multiplexed to PDU if this ok for you

thanks

[ebroecker]

Hi @jazi007 ,

I think I know what you mean. The modelling in canmatrix is not really correct.

But - as is - it works perfectly for some users who create .dbc from arxml.
These created dbcs seem to work fine. Is there a better option for FD-dbc?

So if we change the modellig to we must keep in mind that most formats don't allow PDU containers and we need to simulate somehow.

I am not deep in CONTAINER-I-PDU for now, but there are different "subtypes" of CONTAINER-I-PDU - right?
Maybe creating arxml-snippets for different use-cases would be a great help to understand...

[jazi007]

@ebroecker,

As is. it allow user to have 1 PDU, so it's better than nothing ^^. but for me is not correct. (user will see one PDU decoded and will think he is decoding correctly the complete frame)

And yes, the problem wit contained PDU approach is exactly this. we can't export it to other format.

May be having it optional is a good compromise

1. use Pdu for arxml contained-pdus
2. add option for export to other format to consider PDU contained frames as multiplexed frame or not considering it at all (it would be nice to add a warning for all considered frames)

I have no idea about CONTAINER-I-PDU subtypes. I know only the one I'm speaking about ^^

[ebroecker]

@jazi007

Thanks for the hints, I read AUTOSAR_SWS_IPDUMultiplexer once more and now agree, that my interpretation was wrong.

1. you are complete right - only the first pdu will be decoded (but this will be done right :-)
2. CONTAINER-PDUs without Header-IDs (static layout) should be decoded correct also.
3. But dynamic Container Layout is more or less impossible to modell in dbc

Current implementation is just a hack to support CONTAINER-PDUs somehow, so YES we can improve, any hints are welcome.
Maybe some ARXML-Snippet would be helpful to get started...

[jazi007]

here's a small rework: #576

Let me know what do you think.

regarding the arxml snippet: the one I have are structured like: ARXMLContainerTest.arxml.
ARXML I have are generated using Vector tools and I don't have access to Vector tools to give examples :-(

[Lit-fish-auto]

Generally, the arxml format of CANFD is Frame :: Container-PDU- pdu :: I-signal-PDU :: Signal
If arxml is in the above format, then in python cantools , The method of load_ file（abc.arxml） cannot read the signal(these signals is belong I-Signal-PDU，and tehse I-Signal-PDU is belong Container-PDU- pdu ).
Above, how should this form of arxml be read? or is the bug ？
can you help me ?

dbc = './AS/123abc.arxml'
db = cantools.database.load_file(dbc)
all_message = db.messages
for message in all_message:
print(message)
print(message.frame_id)
print(message.signal_groups)
print(message.signal_tree)

out:
message('FDR_ADCANFD_FrP04', 0x3dc, False, 64, None)
988
None
[]