Does ASN1SCC support extensibility without the use of extension markers?

[amuroh]

Hi,

I'm evaluating the use of ASN1SCC on our projects, but we need extensibility of the SEQUENCES to support forward and backward compatibility fo the PDUs.

I read that ASN1SCC does not support the extension marker, does it support extensibility of the data types and versioning in some other way?

Thank you very much,

Álvaro

[maxime-esa]

Extensibility is out of scope in ASN1SCC because it implies that the message receiver cannot know in advance the size of the message. Therefore it cannot have a static allocation of the buffer to store it and this is incompatible with embedded systems (in space at least) where malloc is forbidden.
To my knowledge there is no other means in ASN.1 to provide extensibility or versionning of a type.

As a workaround, you can probably mimick the extensibility mechanism by allocating a spare space in your type (version 1) and use it differently in following versions. ACN helps by giving fine control over the encoding.

For example:

MyType ::= SEQUENCE { -- version 1
    version INTEGER (0..7), 
    v1      BOOLEAN,  -- fields of version 1
    spare   OCTET STRING (SIZE (1..255)) OPTIONAL -- v1 can receive a future version data with up to 255 additional bytes (+ length field)
}

and in ACN

 MyType  [] {
    version [],
    v1      [],
    spare   [present-when version > 1]    -- optional field presence condition
}

This data structure should be compatible with v1 and optional additional data (up to the size limit defined in the "spare" field octet string). If version is >1 the decoder will expect an octet string (but user will be free to ignore its content).

Then later you can create the V2 like this:

FieldsOfV2 ::= SEQUENCE {
   someNewField BOOLEAN   -- new fields added in version 2
}

MyType ::= SEQUENCE { -- version 2
    version INTEGER (0..7), 
    v1      BOOLEAN,   
    v2      SEQUENCE {
        fields OCTET STRING (CONTAINING FieldsOfV2)
   } OPTIONAL,   -- optional so that we can receive v1 packets
    spare   OCTET STRING (SIZE (1..255))                 OPTIONAL     -- spare for v3
}

then in ACN:

 MyType  [] {
    version [],
    v1      [],
    v2      [present-when version > 1] {
        len    INTEGER [size 8, encoding pos-int],   -- Add a length field so that v1 can decode the data as OCTET STRING
        fields [size len]
    },
    spare [present-when version > 2]
}

You can generate the ICD to visualize the resulting encoding:

$ asn1scc -icdAcn v1.html -ACN v1.asn v1.acn
$ asn1scc -icdAcn v2.html -ACN v2.asn v2.acn

This will provide this table:

for v1:

and for v2:

Of course you can add new versions indefinitely following this pattern.

[amuroh]

Thank you so much for your detailed and fast reponse