Resources
Developing ASN.1 applications is a 4-stage process:
In the first stage, application designers decide on the types of messages their final application(s) will need to send/exchange. Based on the message requirements, a new ASN.1 specification is drafted or an existing one is used.
When drafting new ASN.1 specifications, it is helpful to decide on the encoding rules (e.g., BER, DER, PER and OER) which will be used in sending messages. Doing so will enable the final application to take full advantage of efficiencies supported in the various encoding rules (such as ASN.1 subtype constraints resulting to smaller encodings when PER is used).
Drafters of ASN.1 specifications should also keep in mind possible future requirements (such as message extensibility and a change in the encoding rules used).
Example:
The below abstract syntax is designed to carry simple control and status messages between electric machinery and a remote operator. The machine has two states: on and off. The operator can give the machine a turn on instruction, a turn off instruction, or a no action instruction.
ASN.1 Specification:
-- Machine Control Abstract Syntax
MCAS DEFINITIONS::=
BEGIN
ControlPacket ::= SEQUENCE {
currentStatus INTEGER {off(0), on(1)},
nextAction INTEGER {noAction(0), turnOn(1), turnOff(2)}
}
END
Most ASN.1 specifications are much more complicated than our simple example. Such specifications, when being drafted, often contain typographical and syntax errors which need to be corrected. Manually finding and correcting such errors in long and complex ASN.1 specifications can be an arduous task. Quality ASN.1 tools, such as the compilers and the ASN.1 Studio IDE offered by OSS Nokalva, can pinpoint these errors allowing them to be quickly resolved.
Once all specification errors are fixed, the ASN.1 specification can be input to the ASN.1 compiler to produce data structures and related code for inclusion into your application program. The target language in which the data structures and code are produced varies according to the capabilities of the ASN.1 compiler in use. For example, OSS Nokalva offers ASN.1 compilers that use C, C++, Java, or C# as their target language.
In your application code, you can use the data structures produced by the ASN.1 compiler in much the same way as you would use your own data structures. Additionally, you can use runtime library functions (such as the OSS-provided ossEncode() and ossDecode() functions) to encode, decode, and perform various other functions on application data. You will find that using full function runtime libraries, such as those offered by OSS Nokalva, will both cut down on the time needed to develop your application and increase its final reliability and correctness.
Aids such as the OSS ASN.1 Tools allow you to develop ASN.1 applications for a wide variety of platforms and embedded systems. Application development is made easier, and the range of solutions you can offer is extended.
Once your application is debugged and tested, you can put it into use to send and receive ASN.1 encoded messages. The diagram below illustrates a message exchange between the embedded chip controller and remote computer operator application mentioned in the Stage 1 example.
For a more detailed example of how the OSS ASN.1 Tools work, see an example of how to create an application using the OSS ASN.1 Tools for C.