Adding SREM, SSEM and IVIM messages

[khevessy]

I've added SREM and SSEM messages. I think I have it correct, only thing I am not sure with are the files EXTERNAL.c and EXTERNAL.h, my asn1c compiler keeps generating those but I think they may not be needed. Even after removing /usr/local/share/asn1c, when I reinstall the asn1c from riebl/asn1c/integer_uper, they appear again.

[khevessy]

I tried adding also IVIM messages. See https://github.com/riebl/vanetza/issues/162. I am manually removing "[[" and "]]" characters from https://standards.iso.org/iso/ts/19321/ed-2/en/ISO19321IVIv2.asn, hope it is okay this way.

[riebl]

Hi @Irisbus, can you please cross-check my srem_ssem_ivim branch? I have rebased your commits on the current master branch and would like to merge them. However, I would feel more confident if someone had a look at it before :-)

[khevessy]

Hi @riebl, unfortunetaly I discovered I cannot encode SSEM messages (both in my pull request and your branch) due to this error:

terminate called after throwing an instance of 'std::runtime_error'
  what():  Can't determine size for unaligned PER encoding of type SSEM because of SignalStatusList sub-type
Aborted

When I try to do encode_oer():

terminate called after throwing an instance of 'std::runtime_error'
  what():  OER encoding of type SignalStatusMessage failed because of regExtValue sub-type
Aborted

I know those errors usually come from not correctly filling some structures, but I believe I have everything filled correctly. Do you have any idea where it might come from? I do not think there are any constraints put on the regional extensions.

Also, I have just a question for you, where does the name ITS_Container_Temperature_t and files ITS-Container_Temperature.{c,h} come from? Do you create them manually (changed from Temperature_t)?

[khevessy]

My problem with SSEM messages was caused by me incorrectly filling the regional structures, of course. So that works correctly.

However, I discovered another problem, there is a name collision with IVI messages: there is a type IssuerIdentifier_t, which is long from ISO14816.asn, but it is a CHOICE structure in IEEE1609.2.asn -- used by Vanetza security code. So I propose renaming the type that is here to something like IVI_IssuerIdentifier, I will try to do that tomorrow.

[riebl]

Thanks @Irisbus for your update! These ASN.1 names tend to clash increasingly as we add more and more ASN.1 sources.

Regarding the ITS_Container_Temperature_t: Nothing I have changed explicitly, probably caused by the updated asn1c I have used for code generation.

[khevessy]

I made renaming of IssuerIdentifier_t to pull request #180 on your new branch. I am able to encode/decode SREM, SSEM and IVIM messages on Craton/Secton devices now, so from my side this is ready to merge.

[riebl]

I have finally merged the SREM, SSEM and IVIM messages into the master branch. Next will be your IssuerIdentifier_t PR.