On building SAE J2735 and IEEE 1609.2

[hmusavi]

Lev,

I generated the code for j2735 and ieee1609.2 schemas but building it is giving the following error. In the generated code, there is no INTEGER_free.x file either.

gcc  -I. -o Uint64.o -c Uint64.c
Uint64.c: In function 'Uint64_constraint':
Uint64.c:30:29: warning: integer constant is so large that it is unsigned
  if((value >= 0 && value <= 18446744073709551615)) {
                             ^
Uint64.c:30:2: warning: this decimal constant is unsigned only in ISO C90
  if((value >= 0 && value <= 18446744073709551615)) {
  ^
Uint64.c: At top level:
Uint64.c:49:35: warning: integer constant is so large that it is unsigned
  { APC_CONSTRAINED,  64, -1,  0,  18446744073709551615 } /* (0..18446744073709551615) */,
                                   ^
Uint64.c:49:2: warning: this decimal constant is unsigned only in ISO C90
  { APC_CONSTRAINED,  64, -1,  0,  18446744073709551615 } /* (0..18446744073709551615) */,
  ^
Uint64.c:59:2: error: 'INTEGER_free' undeclared here (not in a function)
  INTEGER_free,
  ^
makefile:1397: recipe for target 'Uint64.o' failed
make: *** [Uint64.o] Error 1

[vlm]

1. IEEE 1609.2 is defined in terms of OER, not PER. From what you're compiling it seems that you have to replace -gen-PER with -gen-OER.
2. I've fixed the INTEGER_free error in the main.
3. Please wait until the end of this week, I'll fix the rest of the problems. See https://github.com/vlm/asn1c/commit/d748bffbfcafa336413b40cdeca310dbb6058154

[hmusavi]

The ASN.1 schema and the encoding rule are somewhat independent, no? I mean, you could build a J2735 PDU object and encode it in OER or have a ieee1609 object encoded in PER, right?

When I generated the code, I supplied both J2735 and ieee1609.2 schema files to the compiler command with both -gen-PER and -get-OER command line options. Is that wrong? Should J2735 and ieee1609 code be generated into separate libraries?

[wjleong]

hmusavi, I tried to build the latest compiler using cygwin32, and ran into "Can't exec "aclocal" issue. how did you compile the source code without issue?

[hmusavi]

@wjleong I built the compiler code on a ubuntu Docker container; did not using cygwin.

[wjleong]

Hello hmusavi,

Thank you for your reply. I am using cygwin32 and ran into some problem. I need the latest asn1c compiler to work in windows10. Since you are able to compile yours can you put a latest version in github so that i can download it. I am trying to get 1609.2 running as well.

Thank you! WJL

On Tue, Aug 8, 2017 at 8:11 PM, hmusavi notifications@github.com wrote:

@wjleong https://github.com/wjleong I built the compiler code on a ubuntu Docker container; did not using cygwin.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlm/asn1c/issues/174#issuecomment-320937075, or mute the thread https://github.com/notifications/unsubscribe-auth/AcjZKYI8f4q9xr-t9Bu_rmRNNGDRXG5Kks5sWFBdgaJpZM4Ov0Zy .

[hmusavi]

@wjleong The compiler is not quite ready for prime time yet to generate code for J2735 and 1609 but it should be ready soon. I am still working on building the compiler and generating code for these schemas. I'll try to push my build of the compiler up to my github repo so you can use it but it probably won't work on cygwin. You may need to do what I did and install Docker and build a docker image from ubuntu. I'll have that pushed as well if you want to go that route.

[hmusavi]

@vlm I think I figured out my own question about combining j2735 and iee1609.2. They SHOULD NOT be combined. The compiler does not generate code for classes of the same name. For example, both standards define Duration, Latitude, Longitude and Psid and each define it differently. The compiler does not generate any of these classes when schemas are combined. I suspect the naming conflicts are causing that and probably output an error message which went unnoticed. Maybe in the future, the generated code for different schema files should belong to different namespaces so there won't be a naming conflicts.

[wjleong]

Hello Hmusavi,

Thank you! That will be a great help. I am going to use C# or Java in VS to generate a high level control from the generated code, so my questions is this...Does your compiler works on Windows10 machine? Does the compiled code (unmanaged) works in Win10 machine? If yes, it will be a super help. Really appreciate your reply!

best regards, WJL

On Tue, Aug 8, 2017 at 10:28 PM, hmusavi notifications@github.com wrote:

@wjleong https://github.com/wjleong The compiler is not quite ready for prime time yet to generate code for J2735 and 1609 but it should be ready soon. I am still working on building the compiler and generating code for these schemas. I'll try to push my build of the compiler up to my github repo so you can use it but it probably won't work on cygwin. You may need to do what I did and install Docker and build a docker image from ubuntu. I'll have that pushed as well if you want to go that route.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlm/asn1c/issues/174#issuecomment-320973245, or mute the thread https://github.com/notifications/unsubscribe-auth/AcjZKeESDp4Oh53XBAEFnw5gOUE7pjCMks5sWHClgaJpZM4Ov0Zy .

[hmusavi]

hi @wjleong

That's a question for Lev. This is not MY compiler. I'm just another user like yourself.

[wjleong]

Anyway! Thank you!!! Appreciate your help too....Lets wait for Lev reply.

On Tue, Aug 8, 2017 at 11:34 PM, hmusavi notifications@github.com wrote:

hi @wjleong https://github.com/wjleong

That's a question for Lev. This is not MY compiler. I'm just another user like yourself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlm/asn1c/issues/174#issuecomment-320993554, or mute the thread https://github.com/notifications/unsubscribe-auth/AcjZKdaWRASI_lH6TT5VTHQkcFfvY3v3ks5sWH_vgaJpZM4Ov0Zy .

[DavidKelleySCSC]

I really want to see Lev's tool be able to handle these two standards. A few of passing remarks.

First: Combing the ASN specifications from IEEE and SAE is a designer/builder choice (and there are several interlinked modules involved in this). Our own firm leaves them separate and appends a rev number (e.g. "-36") to each complete module set, but we have to support both old and new code bases. As the two groups use different encodings (and those choices are normative), and because they each update at different time frames; keeping them separate seems like the more reasonable way to mange development risk to me.

Second: The IEEE 1609 layer defines the use of an OER encoding for some (but not all) of its work. The message payload of SAE DSRC (J2735 in this case as well as other standards) defines the use of UPER as the sole allowed encoding. The process is as follows: The J2735 message set is first encoded in UPER (the 'frame' message is a top level byte aligned message) then handled over to the 1609 layer and treated as an OCTET blob by the 1609 layers (you can call it a protocol data unit if you like that term).

Second, part II: The security details about message sending rights and decoding (the SSP data found in the security certificate as defined in 1609) is defined by SAE DSRC (as the creator of the message) and also encoded in UPER and then carried as an OCTET blob in the senders certificate.

Finally: The SAE J2735 DSRC message set also has within it several other message set structures which are defined by others and generally treated as an OCTET blobs to be transported to the other endpoint. Examples of this include the RTCM messages (GPS corrections) the NMEA-183 messages (primitive location reporting messages), vehicle CAN bus data, and some data type definitions defined by other standards groups such as NTCIP. Thankfully, you do not need to understand how to parse those messages to strip them out and then pass them along.

And to close on my normal two notes: Please do not paste the SAE DSRC ASN specification on public forums, as SAE sells that code. And there is no way to correctly guess how to use these messages from the ASN alone, you need to go get a copy of the actual message set document. (Failing that, ask me)

[vlm]

@wjleong, the asn1c is not trying hard to be Windows-compatible, this is beyond my human means. However, the code generated by asn1c aims to be C89-compatible, so it will work with MSVC and virtually any other C/C++ compiler that we have around.

Normally you should be able to combine specifications and make asn1c to generate a complete support for everything in one pass. If it doesn't work now, there's a bug somewhere. Also make sure you have -fcompound-names to disambiguate things further.

[vlm]

@DavidKelleySCSC, nice to virtually meet you. I also noticed your earlier comments on SourceForge forum. Thanks for the helpful pointers, they help me as well as anyone.

On the more general note, my short term goal is to get asn1c to completely support 1609.2 and J2735. If you have difficulties with them now, don't despair, it is coming in the coming days.

[DanyaFilatov]

@vlm Be careful, the 1609.2-2016 is about to be changed now, having the amendment 1609.2a d8. This version is currently in recirculation sponsor ballot in IEEE. The latest version of ASN.1 module of 1609.2a is accessible on William's github account https://github.com/wwhyte-si/1609dot2-asn

ETSI specification TS103097 was changed to be a profile of 1609.2. It contains some data definitions derived from 1609.2 types with additional constraints. It would be great if asn1c can support it as well. It is in the stage of final draft and will be published within some days. Please have a look to the attached TS103097 asn1 module. EtsiTs103097Module.asn.zip

[DanyaFilatov]

@vlm Actually, I have, as many others, started to implement OER support in my own fork of asn1c. Now, when this task is officially started in master, I would prefer to stop my job. Lev, are you expecting to complete this task in the near future? We really need it for our free ETSI test suites.

[DanyaFilatov]

@vlm, regarding MSVC support of generated code: Visual C has a LLP64 model, so the size of long is 32 bits even on x64 platform. Perhaps, it could be better to use a NativeInteger_t typedef wherever possible instead of using 'long'. If you agree on that, I can make a pull request.

[vlm]

@DanyaFilatov, yes, OER is my explicit short term goal for IEEE 1609.2. Do you have an ETSI standard with OER you'd like me to take a look at?

@DanyaFilatov, I do plan to make more granular thing which is to use the smallest integer type based on non-extensible constraints. Like uint32_t, uint16_t, uint8_t. If you were to do the PR you described it'll likely conflict with this granular-integers effort. However, I'd also wouldn't want you to do the granular integer method yourself because the code is a mess around it and I need some refactoring, and don't want us to step on each other's feet. So if you could just wait a couple of weeks that'd I'd just produce a proper patch for both problems.

[DanyaFilatov]

@vlm, I've attached the TS103097 ASN.1 module to my previous post. It is just a profile for 1609.2. @vlm, of course, I can wait, thanks a lot for your effort. I think this 'granular thing' should also be an answer to the problem of signed long overflow in constraints, right?

[vlm]

@DanyaFilatov, right. Signed long overflow for simple constraints such as (0, ULONG_MAX) is almost automatically handled by just having no constraints on a uint64_t type. The internal conversion then will ensure that bounds are checked.

[vlm]

JFYI SAE J2735 scheme works now in the master branch.

[vlm]

JFYI IEEE 1609.2 scheme works in the master branch as well.

[GouravSh]

@vlm, I have just downloaded the source code from master branch and trying to compile the latest IEEE1609.2 asn file. Although the code is getting generated (only with a 64 bit OS), I think there is an issue. The issue is with handling the Uint64 (i.e. long long) variables. I see that check-oer is passing, but the code is generated with a long variable for Uint64 and Time64 modules. I think this piece need to be corrected. Pls suggest. Following is the warning I see during the code compilation for above modules Uint64.c:30:29: warning: integer constant is so large that it is unsigned if((value >= 0 && value <= 18446744073709551615)) { ^ Uint64.c:49:35: warning: integer constant is so large that it is unsigned { APC_CONSTRAINED, 64, -1, 0, 18446744073709551615 } / (0..18446744073709551615) /,

[nprobert]

The 1609.2 in OER works for me, but I have resorted to a hand built decoder just to get to the J2735 data. The J2735 does not handle namespaces very well and suffers memory leaks and crashes, so I have abandoned asn1c. The J2735-2020 version is being reorganized and modularized and depends heavily on namespaces. I've gone with Marben, but for those on a budget Bellard's FFASN1 should work if you have 2000eu.