Author Archives: Kevin

V2X API Updated for SAE J2735

We’ve updated our V2X API for the latest revision of SAE J2735, revision 202007.

About Objective System’s V2X API

The V2X API is available for C++, Java, and C#.  It supports encoding/decoding V2X messages defined by SAE J2735 and ETSI standards.

The Python and Go wrappers enable easy conversion between binary and text encodings by providing a simple Python and Go interface on top of the C++ API.

For more, go here.

 

Optimization, Licensing, and Performance

Users evaluating our ASN1C SDK frequently find they don’t get the encoding or decoding performance they hoped for.  The libraries we provide for evaluation have less-than-optimal performance for two reasons: they are not optimized and they include license checking overhead. Customers who need to evaluate performance characteristics can request access to optimized libraries, but without doing that, what are some reasonable expectations?

We recently did some performance analysis to help a potential customer evaluate performance. The analysis was for decoding of LTE RRC messages using C++. We used ASN1C 7.4, the statically-linked ASN1C libraries, and Visual Studio 2019. Due to possible variations in specifications, data sets, and hardware, I don’t report absolute measurements here, but rather relative measurements of elapsed wall clock time.

Non-optimized, limited (license-checked) library (baseline) 100%
Non-optimized (debug), unlimited (license-check free) library 72%
Optimized, limited (license-checked) library 47%
Optimized, unlimited (license-check free) library 20%
Optimized, unlimited (license-check free) library, with code generation changes (see below for details) <2% (8.5% of the time for the same library without the code generation changes)

In this test, we found that the optimized, unlimited library used roughly 20% of the time used by the non-optimized, limited library provided with the evaluation SDK (that’s an 80% reduction in elapsed time).

In this particular case, we did some further experimentation to see what could be done with the generated code to get even better performance using the optimized, unlimited library. We found that by removing some generated diagnostics-related code and using dynamic arrays instead of linked lists, we achieved a tremendous further performance boost. (We generated code using the -dynamicArray option and compiled it with _COMPACT defined). By doing this, we found the time used was less than 2% of the baseline, and only 8.5% of the time used by the optimized, unlimited library.

V2X Python Wrapper Updated for Python 3

We’ve updated the Python wrapper in our V2X API packages to support Python 3 (in addition to supporting Python 2.7).   Also, all platforms, not just 64-bit ones, now include the Python wrapper.

About Objective System’s V2X API

The V2X API is available for C++, Java, and C#.  It supports encoding/decoding V2X messages defined by SAE J2735 and ETSI standards.

The Python wrapper enables easy conversion between binary and text encodings by providing a simple Python interface on top of the C++ API.

For more, go here.

V2X API Library Update

With the recent release of ASN1C 7.3.3, we’ve also updated our V2X API library.  We’ve added support for ETSI TS 103 301 SPATEM, MAPEM, IVIM, SREM, and SSEM messages.

Our V2X API library provides support for encoding V2X (Vehicle-to-everything) messages.  The library is available for C++ (as a shared library) Java (JAR), and C# (DLL).   A simple Python wrapper for the C++ shared library is also provided.

Users of previous versions of the Java or C# library should be aware that a slight change was made: classes in the v2x package/namespace have been split into one of two sub-package/namespaces: v2x.j2735 or v2x.etsi.

Users of previous versions of the C++ or Python library should be aware that the shared library has been split into two files (*_j2735 and *_etsi).  Python users must have both libraries present as the Python wrapper library requires both of them.  C++ users can use whichever one is appropriate.

Extending JSON Encoding Rules (JER)

ITU-T standardized the JSON encoding of ASN.1 data in X.697 (JER), but we believe customers want to support use cases the standard doesn’t address.  This post briefly describes two extensions to JER that we’re planning to implement in our ASN.1 compiler, ASN1C.  We plan to implement the first extension (for contents constraints) as an undocumented feature in a 7.3.x patch release in the September-October time frame.

Extension for Contents Constraints

The first extension relates to encoding of BIT STRING or OCTET STRING with a contents constraint.  For example:

OCTET STRING (CONTAINING SomeType)

In short, the purpose of this first extension is to allow the contained type to be encoded in JSON just as it would be encoded if it weren’t a contained type, instead of encoding it as a string of hexadecimal characters.  This extension is all about making the JSON more human-readable.  Here’s an example:

Say your ASN.1 has something like this:

   my-bit-string BIT STRING ( CONTAINING TwoStrings )
…

TwoStrings ::= SEQUENCE {
   one UTF8String,
   two UTF8String
}

The standard JER encoding would look something like:

"my-bit-string" : { "value" : "7B20226F6E6522203A20226D6F6E6579222C202274776F22203A202273686F7722207D", "length" : 280 }

Our extension would instead produce something like:

"my-bit-string" : { "value+" : { "one" : "money", "two" : "show" } }

Extension for Values of Unknown Types

The second extension relates to encoding values of unknown types, which may appear as SEQUENCE/SET/CHOICE extension elements or in open types.  It isn’t possible to convert values of unknown types from BER or PER to standard JER.  Since its type isn’t known, the value is stuck in BER or PER, so to speak.  So, in short, the purpose of our second extension is to enable converting the rest of your data to JSON while preserving what can’t be properly converted (in case you need it) and making a round trip back to the original encoding possible.  This is done by embedding the original encoding in the JSON in hexadecimal form, along with some supplemental information where necessary.

Below are some examples of the JSON that would be produced using our extension.

Handling an unknown open type value:

"some-open-type-element" : { 
   "encoding-rules+" : "BER",
   "encoded-data+" : "03020101"
}

Handling unknown SEQUENCE or SET extension elements:

"extensions+" : {
   "encoding-rules+" : "BER",
   "encoded-data+": [ "hex for extension X", "hex for extension Y" ]
}

Handling an unknown CHOICE extension element:

some-choice-field : {
   "extension+" : {
      "encoding-rules+" : "PER",
      "encoded-data+" : "04020301",
      "encoded-per-index+" : 5
   }
}