Update to ETSI TS 102 637-2 (CAM) and ETSI TS 103 831 v2.1.1 (DENM)

[kubermario]

Description

By approaching to Mosaic V2X application, I've noticed the Technical Specification ETSI TS 102 637-2 used for specifying awareness CAM messages refers to an old specification (V1.2.1 - 2011-03). This applies also for the AwarenessData entity which refers to ETSI EN 302 637-2 v1.3.1 (2014-09). The same reasoning applies to DENM, IVI, SPATM. Is there any interest in upgrading the data format? If not, would it be possible to have some hints on the approach to be used?

...

Affected modules

MOSAIC-OBJECTS => V2X
...

Proposed solution

Update message format to ETSI EN 302 637-2 to V1.4.1 (2019-01) for CAM
Update message format to ETSI TS 103 831 v2.1.1 for DENM
Update IVI and SPATM data to recent standards.
...

[kschrab]

Hi, we have currently no urgent need to update the message format. But we'd available for any help or code reviews!

When we implemented CAM/DENM, we oriented at the mentioned specifications, but did not 100% followed them since we wanted to keep them usable in code. I guess this was the main reason why we did not implement the different frequency containers. Furthermore, various fields cannot be provided by the coupled simulator SUMO, which is why we dismissed them in our initial implementation.

If a full implementation would be required, I also would suggest to use an ASN.1 compiler (e.g. https://github.com/yafred/asn1-tool) to generate matching Java objects. Still, many of those fields would not be able to be filled with suitable values, which could be irritating from a users perspective when getting only dummy values from most of the fields. On the other side, the message sizes would be way more realistic when using the full message format.

[kubermario]

Ciao @kschrab , extremely thanks for the fast reply.
I entirely understand your point; basically , what you are saying is that I could approach the development but it won't be sure that all new fields will match in the underground (e.g., SUMO).

Thanks for pointing the tool, will have a look at it.

Just a fast one: if I want to approach this change, which are points impacted?
I suppose I should start from the lib->mosaic-objects->org.eclipse.mosaic.lib->v2x; is this correct?
This will help me start changing the model. Of course, then, I think I should change utilisers, which are difficult to be found.

Extremely thanks,
m

[kschrab]

The messages defined in org.eclipse.mosaic.lib.objects.v2x.etsi are currently only used by the applicaiton simulator and single applications, and some integration tests. So you should indeed start by implementing new classes which extend V2xMessage and you can (but not have to) orientate towards the current model.
After implementing the messages, you'll need to fill them with values using the CamBuilder and the assembleCamMessage methods in VehicleUnit etc. DENMs are currently constructed solely on application level. SPATM are currently unused by us. Ivim was used during the work presented in this paper to send advices to road users, where we did not focus on a correct message implementation, so they might won't match the standard right now.

I'd propose to create a complete new package in mosaic-objects (org.eclipse.mosaic.lib.objects.v2x.etsi2 or the like) and keep the old classes alive, so we could migrate step-by-step, or use both models in parallel/chosen by the user.

[kubermario]

@kschrab perfect.
Will keep you informed on how it proceeds.
Will surely follow your advices and, once ready, will then go with a merge request.

Thanks for the advices.