Difference between revisions of "Technical topic: Hints to model complex packet encodings with ASN.1 and ACN"

From TASTE
Jump to: navigation, search
(Context: Legacy Binary Encodings)
Line 1: Line 1:
 +
In this page we are giving recipes and hints to help making use of ASN.1 and ACN to model complex packet structures. The example is based on the ECSS Standard named "PUS-C". This standard defines the packet structure for Telecommand and Telemetries used to exchange data between the Earth and Satellites.
 +
  
 
== Context: Legacy Binary Encodings ==
 
== Context: Legacy Binary Encodings ==
Line 8: Line 10:
 
In some situations (actually, ''most of the time''), you need to comply to some pre-established encoding rules, that are explicitly telling you, for a given protocol, how each packet shall be encoded.
 
In some situations (actually, ''most of the time''), you need to comply to some pre-established encoding rules, that are explicitly telling you, for a given protocol, how each packet shall be encoded.
  
ASN.1 is widely used and is very popular because it provided built-in ''standard encoding rules'' that range from compact binary encoding (uPER, standing for ''unaligned Packed Encoding Rules'') to ugly verbose XML encodings. Many telecommunication protocols are using these encoding rules. They allow users to rely on existing tools - you provide your ASN.1 grammar, and the tools provide encoders and decoders following the standard, therefore ensuring inter-operability.
+
ASN.1 is widely used and is popular because it provides built-in ''standard encoding rules'' that range from compact binary encoding (uPER, standing for ''unaligned Packed Encoding Rules'') to ugly verbose XML encodings. Many telecommunication protocols are using these encoding rules. They allow users to rely on existing tools - you provide your ASN.1 grammar, and the tools provide encoders and decoders following the standard, therefore ensuring inter-operability.
  
 
'''However''' sometimes this is not sufficient... Some communication protocols (''too many...'') come with custom, proprietary encoding rules that are incompatible with any existing standard. In those situations, the usual approach consists in hand-writing binary encoding/decoding functions. ASN.1 may look far less relevant in that case, as automation can hardly be achieved...
 
'''However''' sometimes this is not sufficient... Some communication protocols (''too many...'') come with custom, proprietary encoding rules that are incompatible with any existing standard. In those situations, the usual approach consists in hand-writing binary encoding/decoding functions. ASN.1 may look far less relevant in that case, as automation can hardly be achieved...
  
 
Well, this is not exactly true. ASN.1 has two options to deal with that family of problems (legacy encodings). The '''ECN''' language (for ''Encoding Control Notation'' is a full-blown ISO standard that allows to formally describe custom encoding rules. It is powerful, but also extremely complex. '''ACN''', on the other hand, is a light, free and open-source language that was developed to cover the same need but in a ''usable way'' (simple syntax, very close to ASN.1).
 
Well, this is not exactly true. ASN.1 has two options to deal with that family of problems (legacy encodings). The '''ECN''' language (for ''Encoding Control Notation'' is a full-blown ISO standard that allows to formally describe custom encoding rules. It is powerful, but also extremely complex. '''ACN''', on the other hand, is a light, free and open-source language that was developed to cover the same need but in a ''usable way'' (simple syntax, very close to ASN.1).

Revision as of 11:03, 8 June 2018

In this page we are giving recipes and hints to help making use of ASN.1 and ACN to model complex packet structures. The example is based on the ECSS Standard named "PUS-C". This standard defines the packet structure for Telecommand and Telemetries used to exchange data between the Earth and Satellites.


Context: Legacy Binary Encodings

ASN.1 is providing simple contructs to define data types which are independent from implementation languages. ASN.1 helps focusing on your application semantics rather than on how data will eventually be physically represented in memory, for example for network transmission.

This is essential in any kind of distributed systems and embedded systems in general. When you want to send a meaningful set of data over a physical link, you can never count on how your local machine will store it. For example, if you use a type named "t_int16" in your code, you can never be sure that is you memory-dump it and send it as-is to a remote node that it will be properly decoded. Why? Because some machine would store the first byte first followed by the other one, while other would do the opposite. This is one example (endianness), but there are many others.

In some situations (actually, most of the time), you need to comply to some pre-established encoding rules, that are explicitly telling you, for a given protocol, how each packet shall be encoded.

ASN.1 is widely used and is popular because it provides built-in standard encoding rules that range from compact binary encoding (uPER, standing for unaligned Packed Encoding Rules) to ugly verbose XML encodings. Many telecommunication protocols are using these encoding rules. They allow users to rely on existing tools - you provide your ASN.1 grammar, and the tools provide encoders and decoders following the standard, therefore ensuring inter-operability.

However sometimes this is not sufficient... Some communication protocols (too many...) come with custom, proprietary encoding rules that are incompatible with any existing standard. In those situations, the usual approach consists in hand-writing binary encoding/decoding functions. ASN.1 may look far less relevant in that case, as automation can hardly be achieved...

Well, this is not exactly true. ASN.1 has two options to deal with that family of problems (legacy encodings). The ECN language (for Encoding Control Notation is a full-blown ISO standard that allows to formally describe custom encoding rules. It is powerful, but also extremely complex. ACN, on the other hand, is a light, free and open-source language that was developed to cover the same need but in a usable way (simple syntax, very close to ASN.1).