vlm / asn1c

The ASN.1 Compiler
http://lionet.info/asn1c/
BSD 2-Clause "Simplified" License
1.04k stars 555 forks source link

Issue compiling J2735 ASN1 with J2945/3 RoadWeatherMessage extension #420

Open BrandtHill opened 3 years ago

BrandtHill commented 3 years ago

I have found a workaround, but I still believe it's an issue, so creating one here.

Background

Following the example in examples/sample.source.J2735, one can create source files for the SAE J2735 DSRC Message Set as well as an executable utilty, j2735-dump, which allows the encoding/decoding of J2735 payloads.

Another standard exists, SAE J2945. This document/standard, J2945/3, defines a new message type: the RoadWeatherMessage, or RWM for short. Annex I in the document provides an ASN1 definition for the RoadWeatherMessage and Annex J provides instruction on how to edit the J2735 v2016 ASN1 file to include the new RoadWeatherMessage type as a possible data type for MessageFrame and a few additional, optional fields for the TravelerInformation.

Upon editing the J2735_201603.asn1 file, your file should contain a new RoadWeatherMessage module and a handful of additions to the DSRC module.

Compilation Issue

Before editing the asn1 file, I made a copy at J2735_201603_original.asn1. By editing the Makefile to use this original file instead, I ran make and the result is as expected: an executable j2735-dump that functions correctly.

Now, while pointing the Makefile back to the edited asn1 file, (running make distclean first) an errors occurs at the ProbeVehicleData point:

cc -DASN_CONVERTER_TITLE="J2735 DSRC decoder" -DHAVE_CONFIG_H -DJUNKTEST -D_DEFAULT_SOURCE  -DPDU=MessageFrame -DASN_PDU_COLLECTION -I. -o ProbeVehicleData.o -c ProbeVehicleData.c
ProbeVehicleData.c:98:4: error: ‘asn_DEF_Snapshot’ undeclared here (not in a function); did you mean ‘asn_DEF_SnapShot’?
   &asn_DEF_Snapshot,
    ^~~~~~~~~~~~~~~~
    asn_DEF_SnapShot
converter-example.mk:23: recipe for target 'ProbeVehicleData.o' failed
make[1]: *** [ProbeVehicleData.o] Error 1

What I think is happening

In the existing DSRC module, a type Snapshot exists:

Snapshot ::= SEQUENCE { -- stuff... 

This type is only used once, in ProbeVehicleData (where the compilation error occurs):

snapshots       SEQUENCE (SIZE(1..32)) OF Snapshot, 

The additional RoadWeatherMessage module brings a new type SnapShot:

SnapShot ::= SEQUENCE { -- other stuff...

The issue seems to be due to the similarly named types that differ only the capitalization of the second 's'.

My workaround

The new SnapShot type is referenced only three times: its definition and two members. I changed SnapShot to RwmSnapShot by editing the following lines

RwmSnapShot ::= SEQUENCE { -- previously SnapShot ::= SEQUENCE {

-----...

RoadWeatherUpload ::= CHOICE {
    vehicleReport   SEQUENCE (SIZE(1..32)) OF VehicleReport, 
    citizenReport   RwmSnapShot, -- previously   citizenReport    SnapShot
    ...
}

VehicleReport ::= SEQUENCE {
    snapShot         RwmSnapShot, -- previously   snapShot    SnapShot
    wdmsFleetData    WDMSFleetData      OPTIONAL,
    ...
}

After changing the name to avoid conflict, the compilation is successful.

Is the library case insensitive? Is this a known issue/limitation?

DavidKelleySCSC commented 3 years ago

Key: Your proposed solution is correct and will interoperate with others (which is the key thing). This is the preferred method to solve name conflicts of this type (asn1c is prone to this while ASN tools are not).

Extra credit would be to send an eMail to SAE corporate showing what you did and recommending that the relevant committee consider to rename to new type to be 'RwmSnapShot' (look at the first couple of pages of the standard for details).

In this standard (SAE J2945/3) SAE used a new editor who had a bit less experience in ASN and in checking his work. In prior SAE J2735 standards and other prior volumes of SAE J2945/x the editor (myself) would cross check to detect and correct such dupes as well as looking at other "ITS" standards for similar content. Also be mindful that this specific standard does not follow the common name space and module naming rules used for 15+ years in other ITS/DSRC work of the time (from SAE, IEEE, NMEA, and others).