Info export for the Flexray signals defined in the arxml file

[sky-dream]

current now the arxml.py in the formats package can not export the flexray signal attributes out, when i adjust the arxml.py to export the flexray signals, the attributes, slot ID info and the Cycle Time info is not so good due to the net frame ID handling function in the canmatrix.py for arbitration_id and the frame cycle time handle function. can you help optimize the package to support exporting the flexray signal attributes from the arxml file? related code block as below,

 arbitration_id = attr.ib(converter=arbitration_id_converter, default=0),
 store_frame_timings(target_frame, cyclic_timing, event_timing, minimum_delay, repeats, starting_time, time_offset, repeating_time, root_or_cache, time_period, ns, float_factory),
 value = get_child(repeating_time, "VALUE", root_or_cache, ns),
 target_frame.cycle_time = int(float_factory(value.text) * 1000)

[ebroecker]

first of all - did you use development branch or arxml_sameip branch?

Please use arxml_sameip branch where I already started with flexray import. Please give some explicit detail what information would be needed / should be used for export. I am very welcome to integrate this in the branch.

We can discuss here or in #426

P.S. in branch arxml_sameip you can use the option decode_flexray or on command-line use --arxmlFlexray

[sky-dream]

hi ebroecker, i checked the new branch arxml_sameip, but still need some more attributes, i hope you help help export below attributes out into excel tables with the format module arxml.py, PDU type, PDU name, frame base cycle, frame repetition cycle, signal group , signal value description(meaning), tks very much for your kindly support!

[ebroecker]

do you have the details in the ARXML? This would be a great help!

• [ ] PDU type
• [ ] PDU name (already done?)
• [ ] frame base cycle
• [ ] frame repetition cycle
• [ ] signal group
• [x] signal value description(meaning) (already done?)

@sky-dream could you please comment if PDU name and signal value descritpion is already done?

[sky-dream]

hi ebroecker, related xml tag as below,

<I-PDU-PORT-REF DEST="I-PDU-PORT" > (PDU type)
<PDU-TRIGGERING> ---- <SHORT-NAME> (PDU name )
<BASE-CYCLE> (frame base cycle)
<CYCLE-REPETITION>  (frame repetition cycle for flexray) (or translate it to the frame cycle time with repetition and base cycle)
<I-SIGNAL-GROUP > ---- <SHORT-NAME> (signal group name )
<signal value description> (done, value meaning description is in the signal description in the SYSTEM-SIGNAL TAG),

for the output info frame ID,frame length, frame time cycle, channel, signal group, signal , if the format can like as below, it will be much better,

FrameID / SlotID-BaseCycle-Repetition	FrameLen	FrameRate (ms)	Bus Channel	PDU type	PDU name	SigGrp	Sig
0x123	8	50,000	ChassisCAN1			SigGrpx1	xxxxxx
0x456	8	25	ChassisCAN2			SigGrpx2	AxxxxSts
1-0-1	64	5,	Flexray			SigGrpx5	AxxxxID
24-2-4	64	5,000	Flexray			SigGrpx8	Bxxxxld

[ebroecker]

Are you sure, you want the PDU-TRIGGERING/SHORT-NAME ? Current I use I-PDU/SHORT-NAME which seems more human readable in some cases.

[sky-dream]

@ebroecker , just check the arxml structure, your choice

<I-SIGNAL-I-PDU >/ <SHORT-NAME>

is better than mine

<PDU-TRIGGERING  >/ <SHORT-NAME>

for the attribute PDU name.

[ebroecker]

@sky-dream I did some basic prove of concept in branch arxml_sameip: try examples/fr_dump.py your_arxml.arxml

[ebroecker]

@sky-dream did you try examples/fr_dump.py?

[sky-dream]

@ebroecker , I tried your new delivered code in the arxml_sameip branch with the test module fr_dump.py use my arxml signal database of the Auotsar 4.0.3 as the input, still some xml tag searching error, then i update 3 related modules and deliver the code in my fork repo, detail committed code change as below, https://github.com/sky-dream/canmatrix/commit/adc389b47afd3f3c0e5453ba8ee2eb8f338ba202, when i first use the former version

get_signals(pdu_sig_mapping, target_frame, root_or_cache, ns, None, float_factory)

the result is confused, then i saw you fix the error with the new argement pdu for the get_signal function,

get_signals(pdu_sig_mapping, target_pdu, root_or_cache, ns, None, float_factory)

When i check the data handling process in the function decode_flexray_helper() and decode_canhelper(), current now the data process are not following the same order, but i think the main difference in the arxml for can and flexray is the slotID and can frame ID in the frame and the cycle time related attributes in the I-PDU tag, so i think if the data handle process can be unified , then if any user want to change some output feature for both flexray and can signals defined in the same arxml, then it will be much easier. Another little suggestion i want to say is that is it possible we add prifix such as 'xml', 'struct_' to distiguish the different type objects which with the same name, for example, the variable 'frame' can be a xml etree frame object , also it can be the canmatrix object element frame, and it maybe wrongly used,

frame = pc.findall('.//' + ns + "CAN-FRAME-TRIGGERING")
frame = canmatrix.Frame(size = frame_size, arbitration_id = frame_counter)

And there are many similar xml tag object, if we use different variable name for all of them, then the code maybe more understandable, some example as below,

<CAN-FRAME-TRIGGERING UUID="ta2ed8866-2f76-3712-985e-a7551f8e8964">
<CAN-FRAME UUID="22ff0881-c282-47f0-ae5c-be12a314b928">
<FLEXRAY-FRAME-TRIGGERING UUID="tAd0b3a4d5-89ba-3c3a-b777-1f56a8a031c4">
<FLEXRAY-FRAME UUID="c9699f1b-8f67-4e5f-b7e2-0b76e484eccf">
<I-SIGNAL-I-PDU UUID="62824eb4-352e-4190-8081-5a539ab2db56">
<PDU-TRIGGERING UUID="t1dd61bb79-44fa-42a0-8eb5-aa6032d1fdf5">
<I-SIGNAL-TRIGGERING UUID="t_0is00c7ddf7-96ae-4dc8-9fa3-1a8539399076_0">
<I-SIGNAL UUID="isDCE:29d3f557-086f-63d4-9449-12ff836ff20f">
<SYSTEM-SIGNAL UUID="CNN:29d3f557-086f-63d4-9449-12ff836ff20f">

[ebroecker]

hi @sky-dream thanks for your detailed answer.

1. you are right, datahandling difers from can to flexray. But I think this is needed, because flexray structure is different from can structure. Additional canmatrix is constructed arround can. This makes is not easy to support flexray without bigger structural changes. This is what I am not sure how to to it right and thus trying arround...

2. you are absolutely right, that names are more than confusing in arxml-module.

As conclusion, I'll start first of all with refactoring the variable-names through the whole module. This would help us discussing the needed changes

[sky-dream]

hi @ebroecker , agree with you that it is not easy to unified the handling process for can and flexray signals, since i just need to fulfill my request to export can and flexray signal attributes from AR4.0.3 or 4.2.2 arxml, so it is easy for me, but you are maintaining a common data process library for so may different net signals database file, you need to consider more factors. And i must thank you sincerely for your code sharing, so that i can implement my request base on your good design of the code and structure.

[sky-dream]

hi @ebroecker ，i think one more function

get_pdu_info（pdu）

should be added in the xlsx.py and xls_common.py since there maybe someone else also need to get pdu attributes exported, not only just me.

[ebroecker]

basic support implemented

please open an new ticket for new feature requests...