Implement automotive functionality on EDGAR for enabling restbus integration and flashing

[mrh1234]

General idea:

Restbus simulation:

• Implement ARXML parser to filter out CAN messages relevant for restbus simulation
• Execute restbus simulation by utilizing Linux Kernel CAN Broadcast Manager

Flashing:

• TBD

[mbfm]

This library might be very useful: https://crates.io/crates/autosar-data

[mrh1234]

This library might be very useful: https://crates.io/crates/autosar-data

I will stick with programming my own parser. The time-intensive operations of my parser are already implemented and take less than 1 minute for parsing a 325 MB example ARXML file. With optimizations at a later stage, I might even decrease that time. In comparison, the autosar-data library takes more than 6 (!!) minutes for parsing the same file.

[kKdH]

Hey @olFi95 did you face similar performance problems when parsing ARXMLs with autosar-data? Do you have some tips?

[mrh1234]

I had a bug in my time measurements and the autosar-data library is indeed performant. So, I will use it.

[mrh1234]

Status update: ARXML parsing itself is implemented in the restbus-simulation branch. Next, I have to decapsulate the parser a little bit and start to integrate into into Edgar. Currently, it is independent of everything. Furthermore, I have to setup the restbus simulation that takes the output from the parser and plays the messages for a given CAN cluster/bus. This is currently under work.

[mbfm]

I just had a quick look over the code, I don't fully understand it yet and don't know what you had already planned, but quick feedback:

• A unit test would be really important. Otherwise, no one but you will be able to touch this code. Is there maybe a minimal ARXML file, which we can place into the repo and have it parse that?
• Modularizing the code would be good. That's a lot of lines of code for a single file. Some of those structs and helper functions could be moved out of that file. Particularly, you don't have to put them all into the impl for ArxmlParser.
• The test_data()-function and some of the other println!-calls might not be necessary.
  • If this is just a debug output, then deriving the Debug would give you basically the same without that much boilerplate code.
  • If this is output to be shown to the user, then you'd want to implement the Display trait instead. In that case, you could adjust your existing implementation to use writeln!() instead of println!().
  • If this is a fixed output to be handed between processes, then it might make more sense to serialize it out as JSON. For that, you would use Serde, which is similarly simple as the Debug-output (derive the Serialize trait and use serde_json to write it).
  • If this is a fixed output to be handed between processes and it has to be this specific format for some reason, then your current implementation with the println!()-calls would make sense.
• I would strongly recommend rebasing onto development regularly. We're working with a linear history (rebases instead of merges), so a rebase would need to happen at the end anyways. If you do this regularly, each individual rebase will be much less likely to have merge conflicts (and those conflicts will be trivial to resolve). As you've mostly been working in a new file, there won't be many conflicts right now anyways.

[mrh1234]

Thank you for your feedback!

A unit test would be really important. Otherwise, no one but you will be able to touch this code. Is there maybe a minimal ARXML file, which we can place into the repo and have it parse that?

Yes, there a some sample ARXML files. I will find a good one and place that into the repo + integrate a unit test using it.

Modularizing the code would be good. That's a lot of lines of code for a single file. Some of those structs and helper functions could be moved out of that file. Particularly, you don't have to put them all into the impl for ArxmlParser.

I agree. This is almost done on my side and will be pushed soon. Also all the structures will be defined in a separate file, so that they can be imported and used by other files including the upcoming restbus-simulation.

If this is just a debug output, then deriving the Debug would give you basically the same without that much boilerplate code.

Yes, it is just debug output. Good idea. I will use that.

I would strongly recommend rebasing onto development regularly. We're working with a linear history (rebases instead of merges), so a rebase would need to happen at the end anyways. If you do this regularly, each individual rebase will be much less likely to have merge conflicts (and those conflicts will be trivial to resolve). As you've mostly been working in a new file, there won't be many conflicts right now anyways.

You are right. I will do that.

[mbfm]

Hey, I saw that you merged your changes onto development. It's not a problem, but you misunderstood me, when I said you should rebase your branch onto development.

What I meant with that, is that you should update your own branch. Basically, your commits will afterwards sit on top of the latest commits on development. You didn't need to make changes to development yet.

In principle, a rebase should be doable with the following commands:

git checkout development
git fetch
git rebase
git checkout restbus-simulation
git rebase development
cargo ci check  # check that things still fundamentally work
git push origin restbus-simulation --force-with-lease  # force-pushes should be avoided, but if you're working on your own branch, it's not a problem