Abstract Syntax Notation One for MMS

Introduction to the subset of ASN.1 required for MMS.




6.1 Problem Definition

For the encoding of messages to be exchanged the red pencil tactics are too often used, in the opinion: The shorter the message, the better. See also the Y2K problem that has mainly been caused by this red pencil tactic: save bits. We want to counter this common opinion with a short story, before we deal with the question of coding generally and in connection with MMS.

Salcia Landmann writes in the book "The Jewish joke":

"A young father proudly telegraphs to the parents of his wife: "Rebekka happy given birth son". This scarce but quite informative text is written in the typical telegram style. One certainly cannot reproach this text for language abundance. Nevertheless the father-in-law takes the sender of the telegram to task and bombards him with the following reproaches: "How can one be so reckless and throw his money down the drain for superfluous words in a telegram! Look for yourself: You write "Rebekka" - who else? Would you actually telegraph if a completely strange woman is going to have babies? And then "happy" - Since when does one telegraph if a birth does not go well? And now even "given birth" - what else? Were you afraid I might believe, the stork had brought the child? And finally "son" - with daughters the joy is never so great that one would run to the telegraph office. Therefore, we would have guessed this certainly!"

The teaching of this story is that with adequate knowledge of the context an empty message (an implicit information) suffices to convey a complete message to the receiver. However, our language generally lives on even superfluous statements or redundancies. These have the feature that they often help to recognize and to correct errors. This is valid also in the area of communication between technical systems.

If the communication between technical systems is predominantly defined by implicit suppositions, then it is frequently difficult for receivers (these can be applications like diagnostic tools) to recognize errors in the structure and in the contents. At the beginning of our considerations, a technical example is helpful to understand the difficulties.

Technical example

Let's assume two Integer16 (= four octets) were transmitted by a device till now. Only the four octets were transmitted without any further identifications (transparent transmission of the values). Because from now on four data shall be transmitted and because for all four only values smaller than 100 decimal need to be transmitted, it makes sense to divide the four octets up into four Integer8. Regarding the transmission on the line, nothing changes - four octets will continue to be transmitted. However, the receiver must know that the structure of the data has changed. It must be informed that the four octets are to be interpreted as four data of one octet each.

The information that the structure has been changed can be communicated to him via local configuration. At least, this is always necessary for the application because it receives now four instead of two values. These four values must be integrated into the application.

Since such changes of the configuration must possibly be carried out in many devices under various responsibility, it must generally be assumed that at the time of the re-configuration the modification still was not carried out in some places. In this case unnoticed errors will occur in these places which cannot be recognized by the communication either.

If, however, the data types for the values were enclosed during the communication, the receiving side could immediately see the missing agreement of the types: The receiver has expected two integers till now, and suddenly it receives four integers. This error could immediately be recognized and dealt with on the receiving side.

This example clarifies that in addition to the user data further information is important and helps to figure out changes in the data structure. The additional information is necessary, primarily then, if the data to be transmitted vary in their length from transmission to transmission. If of ten values one can be missing, then it must be possible to indicate this.

The opinion - sometimes still to be found today - that modern encoding rules are too complicated and consume too many resources is often caused by the missing understanding of these rules. Current implementations show that these encoding rules are - with regard to performance and real-time ability - much less problematic than generally assumed. In most cases, the communication is by far quicker than the programs of the connected applications. In the following, the most essential features and capabilities of ASN.1 (the commonly used syntax notation) are introduced and discussed with a real example.

MMS defines an external interface (line interface) or the externally visible behavior, the (abstract but also actual) coding as well as sequences and meanings of the interchanged requests and their answers. Client and server can be connected - via a communication network - locally (just some meters from each other) but also over a distance of thousands of kilometers.

As shown in figure 26, the information to be exchanged (in MMS this information is called PDU - Protocol Data Units) must be agreed upon between transmitter and receiver. These agreements are for example:

• kind of the request (read or write, ...).
• number and meaning of the parameters which are part of a request.
• distinction of the direction (request or answer).
• distinction of several similar requests; if for example two read requests (Read "A" and Read "X") are sent to the same server within a short time period, then it must be possible to assign the two answers to the requests again (to "A" and to "X").
• coding of the data (the data types for the transmission must be defined, or at least the length; and the data must be transparent).
• definition, whether the highest-order bit of an octet is sent first or last.
• and many other agreements.

Figure 26: Requirement for formal syntax (principle)

 

Essential aims of these definitions are:

• to facilitate the communication between transmitter and receiver (communication presupposes syntactic and semantic definitions).
• to ensure completeness and consistency of all information to be exchanged.
• to facilitate the receiver to check the received messages on correctness and consistency (incorrect messages are directly rejected by the communication).
• to facilitate the definition of the application data (process data like messages, states, counted measurands, ...) also outside the communication - on paper - and to facilitate the exchange of the definition electronically.

The following consideration assumes as a fact the necessity of a formal coding. The concepts and procedures which are relevant for MMS and IEC 60870-6 TASE.2 are discussed.

Three levels of the coding are represented in figure 27. At first, the communication is described verbally for every connection between systems or devices - for example: the service "reading several variables" is provided for a client in a single request. The definition of the variable can also be carried out verbally - for example: variables represent groups of information provided with types; every part of the group can have a component name (optional); every part can be read for itself; variables can be identified by name or index; the structure of the variables can be simple (bit, integer of ...), and complex (array and structure); etc.

Figure 27: Levels of encoding

It is easily recognized that the continued detailed prose definition of the variables would result in an extensive model. One of the most essential features of MMS is that a data modeling language (MMS variable model) and the abstract coding description language (ASN.1) are linked together to a large extent.

Very often, this first level is only described incompletely. For most cases, the specifications are described in a computer oriented description method - in our case ASN.1. This second level always only describes - regarding the transmission - what is being transmitted. This is done in an abstract way. Abstract here means that the transmission of necessary additional information (such as indications of length) is refrained from.

How the data are then transmitted in a specific case, is independently defined by the second level. The Basic Encoding Rules for ASN.1 (ISO 8825) decide how the information (the MMS PDU) defined in a given protocol (= the set of all syntactic definitions) must be converted into "bits on the line".

There are various standardized actual encoding rules (for example BER and PER) for one abstract encoding rule (ASN.1). In connection with MMS and TASE.2, basically only BER is of importance. Therefore, only this one is given attention to here. In order to be able to understand various actual codings in principle, this will be discussed with a simple example.

Example

Assuming three values of equal type (integer) and equal length (1 octet) have to be transmitted. Viewed abstractly, the syntax for the task to describe several similar values - e. g. in ASN.1 - is:

SEQUENCE OF Integer8

This definition expresses that arbitrarily many Integer8 can be strung together. How can three values be transmitted now? Two examples shall show that there are in principle various possibilities - independent of the abstract syntax definition (SEQUENCE OF ...):

 

Possibility 1:

Description of equal values only in one place:

Number of equal elements (= 3)

+ Type of every element (= integer)

+ length of every element (= 1 octet)

+ value of the 1st element (= 1 octet)

+ value of the 2nd element (= 1 octet)

+ value of the 3rd element (= 1 octet)

 

Possibility 2:

Description of every value independently of the others:

Type of the 1st element (= integer)

+ length of the 1st element (= 1 octet)

+ value of the 1st element (= 1 octet)

Type of the 2nd element (= integer)

+ length of the 2nd element (= 1 octet)

+ value of the 2nd element (= 1 octet)

Type of the 3rd element (= integer)

+ length of the 3rd element (= 1 octet)

+ value of the 3rd element (= 1 octet)

Assuming that every line corresponds to one octet, six octets are transmitted in the first case and nine octets in the second case for the same information. The substantial difference consists in the structure of the description and in the overhead for the interpretation of both messages. In the first case, having interpreted the first three lines, a loop can run through the following values. In the second case, for every value, first the type must be interpreted, then the length and then the value.

The first possibility is obviously much more efficient than the second one - primarily for many equal values. In the case that the values are of various types and lengths, the second method (3 lines per value) is more efficient than the first one (4 lines per value, if all values are different from each other).

This example makes clear that the optimal encoding rule does not exist. What may be optimal for one case, is less efficient for another case. Since MMS supports flexible structures in services and has an extensive data modeling language (variable model), a flexible encoding rule is also necessary - and this is ASN.1. The communication and the description of the application data (data model) converge in this place. Thus, ASN.1 is more than a rule for the encoding during the transmission over the line.

MMS uses a small subset of the ASN.1 description language and of the affiliated BER encoding rules. The following explanations are sufficient to understand in principle the data modeling and the encoding rules. The syntax of the MMS definitions can thus be understood. The latest version of ASN.1 offers a complete object-oriented description method which is also used in the MMS revision (international standard of the MMS revision will be published in 2000).

6.2 Basic principles of the abstract syntax description (ASN.1)?

The applications are generally implemented by means of a specific programming language (see figure 28). The language ASN.1 can be used both for the definition of the services and for the modeling of the application data. The variable model defines the structure discussed above in the form of e. g. Named Variables or Named Variable Lists, Type Descriptions (paths or subpaths) etc. The "bits on the line" are defined by ASN.1 BER.

An excellent ASN.1 Book is available for free download at:

Figure 28: Use of ASN.1 in MMS

At first the encoding of messages is discussed.

6.2.1 ASN.1 for the description of the MMS Messages

The ASN.1 basic elements, represented in figure 29, are important for the description of the MMS Message syntax. Most MMS definitions can be described by these four "LEGO bricks" of the description language. The examples in figure 29 merely provide the fundamental understanding of ASN.1.

CHOICE: The first element is the CHOICE. If from a given number of possibilities one shall be selected, then this is indicated by the keyword "CHOICE" preceding the curly brakkets. The possibilities are listed in the curved bracket. The square brackets [x] contain a serial number which starts with 0 and which needs to be unambiguous only within the square brackets. Thus, many of such branches can be defined quite simply – only the possibilities need to be written down and provided with a number respectively.

SEQUENCE OF: Simple and complex expressions which are in the curved bracket can be repeated arbitrarily often or strung together by using SEQUENCE OF. If there is more than one expression within the curved bracket, then these expressions must also be put in brackets. This is done using the simple SEQUENCE expression.

SEQUENCE: If several simple or complex expressions are listed, then these must be marked by the keyword SEQUENCE and a curved bracket around the expressions.

OPTIONAL: If an element can alternatively be inserted or left out, then this is indicated by the keyword OPTIONAL. In the sequence it is mandatory for the tags [0] and [1] to be included in a received message with this syntax; otherwise the message will be rejected and an error be sent to the transmitter. If the second tag is marked by OPTIONAL, then the element may be missing.

DEFAULT: Another keyword (not represented in the figure) is DEFAULT. It indicates to the transmitter which value is registered in the message, if the application doesn't specify any other value.

Recursion: A recursive structure results whenever the beginning of the definition is referred to within a definition. As example, refer to the MMS specification in figure 10.20 where the type specification was used within the arrays and structures. Of course, the definition of a path must end some time at a simple type (the leaves). There isn't any specific keyword for recursive structures.



Figure 29: Basic elements of ASN.1 used in MMS

These recursive structures and the referencing of definitions, which are defined somewhere else in the MMS specification, allow very compact definitions. This compact representation aggravates the readability, though. Because we cannot imagine nested structures so easily, some that tried to understand the MMS syntax believe it were to complicated. The reading of the following pages will certainly make clear that the system is not complicated but complex, at the most. What we cannot (easily) imagine isn't necessarily complicated.

The structures defined with these modules form, if represented graphically, complex syntax trees. A Hypertext database with the complete MMS syntax can give further insight. It is found at the following address:

ASN.1 defines further keywords such as the basic data types integer, octet string etc.

6.2.2 Extract from the MMS syntax tree

Some extracts from the MMS syntax (ISO 9506-2) are shown and discussed in the following analysis. The structure shown in figure 30 defines some MMS PDU, namely those which know both a request and an answer (Confirmed Service Request) - there are also Unconfirmed Service Requests, for example Information Report. It has to be taken into account here that this branch (Confirmed Service Request) is not at the beginning of the complete MMS syntax tree - the beginning is not represented.

MMS defines about 70 different Confirmed Services, of which the first eight are listed in figure 30.

 Figure 30: Excerpt of MMS syntax tree

The service write (write request) - in yellow shade - is analyzed a little more precisely. The corresponding tag is [5]. The keyword IMPLICIT is irrelevant for the comprehension of the parameters of the write request. The expression write (written in small letters!) is replaced by the expression Write Request (written in capital letters). Now we must search for the definition of Write Request and replace the expression. This replacing must be continued till the "end" of the definitions is reached, i.e. till no expressions need to be replaced any more. We will have arrived then at a so-called terminal expression.

Figure 31 shows the further syntax. The Write Request gets replaced by a SEQUENCE of two elements (Variable Access Specification and List of Data). It is plausible that the variable and the affiliated data must be specified. We don't want to discuss the SEQUENCE OF of data any longer here.

Figure 31: Write syntax

The Variable Access Specification is replaced by a CHOICE with the two possibilities List of Variable and Variable List Name. If data are written to a Named Variable List, then the name is directly specified here (Variable List Name). Thus, just the Object Name still needs to be replaced.

If something shall be written to a Named Variable, then the possibility List of Variable will be selected. Since we want to disregard the Alternate Access here (is OPTIONAL anyway), the List of Variable will be replaced by repeating the variable specification. Here, we merely want to discuss the variant Name which is replaced by the Object Name. If writing to a Named Variable List Object, only the name (Object Name) needs to be specified.

After having discussed the Write Request syntax, we can - for the case "write of an individual variable" - reduce the syntax to three elements: Write Request, Variable Name and value (see figure 32).

Figure 32: Write syntax expanded for one example

If the Write Service merely included the write of a single variable with Object Name, the definition would be correspondingly simple. Then most elements from the Write Request syntax tree would not need to be part of the definition. Due to the high flexibility (one or several variables, with/without Alternate Access etc.), an extensive syntax tree results which, however, for simple applications also gets simple (such as the writing of just one variable). Minimal additional expenses are necessary for coding to be able to distinguish the individual possibilities - a receiver must be able to recognize for example whether only one name and one value instead of several names/values were received.

The MMS syntax has the feature that it offers a compact representation for a variety of possibilities. Only when expanding the syntax (i.e. replacing the expressions as carried out above) the variety will be recognized. This variety cannot be represented easily and therefore is not easily comprehensible. Actually, this syntax is intended for the automatic check of the completeness and consistency (on both sides - sender and receiver) as well as for the implementation of MMS syntax generators and interpreters.

The support which is offered in this place is rather intended for experts who want to get occupied with MMS in detail. For the understanding of the MMS functionality this knowledge isn't required. The MMS service description (ISO/IEC 9506 part 1) contains the description of the functionality without ASN.1. However, it has turned out to be favorable to read the syntax because it is much more compact and precise than a verbal description.

6.2.3 The basis of the ASN.1 Basic Encoding Rules (BER, ISO 8825)

For the further analysis of the MMS messages, the most important details for the actual coding are introduced now. Since ASN.1 - BER included - contains many more definitions than used by MMS, only the features most important for MMS shall be discussed here. With the definition of the MMS syntax for Address (attribute of a Named or Unnamed Variable), shown in figure 33, the individual steps are explained - down to the actual bit coding.

At first, the definition of the OCTET STRING is considered isolated (without tag [2] and without IMPLICIT). This definition is written with capital characters indicating an ASN.1 keyword. The definition OCTET STRING can be found in ASN.1 (ISO 8824).

ASN.1 has, among other things, the following keywords with a tag of their own relevant to MMS:

UNIVERSAL 1 UNIVERSAL 2 UNIVERSAL 3 UNIVERSAL 4 ... UNIVERSAL 16 ...

Boolean type Integer type Bitstring type Octetstring type Sequence and Sequence-of types

The keyword IMPLICIT which is explained below and the keywords OPTIONAL as well as DEFAULT have no tag of their own. These tags will merely be needed for encoding/decoding. All definitions in MMS which aren't replaced in the MMS syntax are written in capital characters. The definition OCTET STRING in MMS is identical to the definition UNIVERSAL 4 octet string in ASN.1. The keyword UNIVERSAL 4 marks this element as an ASN.1 Univeral Class. Universal means that for example octet strings are defined here - and thus only once - for all applications that use ASN.1. The value 4 specifies the selection.

Figure 33: Abstract encoding of the MMS Address

For the actual coding we consider a given value of the octet string in hexadecimal format (figure 34). The three elements: Type (= OCTET STRING), Length (= 5 Octets) and Content (= 24 65 4F EF F3 hex) are necessary for the interpretation on the receiving side. The ASN.1 BER code all three elements; however, the keyword IMPLICIT also offers optimizations which allow an optimized encoding.

Figure 34: T-L-C Definition used in ASN.1-BER

The type integer offers further optimization. Even if the TypeDescription of a variable contains an integer, for example of length 64 bits (Integer64), only the actual length will be transmitted. If the value is smaller than 256, then only one instead of eight octets will be transmitted.

Figure 35 shows the actual coding according to ASN.1-BER. The values for all three elements can be seen in the upper row: 04 hex, 05 hex and 24 65 4F EF F3 hex. The definition of the three elements is below. The eight bits of the type are subdivided in three groups. The first two bits define the class which specifies the scope. All tags defined in ASN.1 are defined as Universal Class. The tags defined in MMS have context-specific Class.

The second group (one bit) describes, whether or not the Content is structured further - with ASN.1 BER. If the Content is structured, then this element in turn contains three elements (T-L-C); the contents of the second Content can also be constructed again etc. This algorithm allows arbitrary nestings. If it is a primitive representation, then only one Length and one Content field follow. The third group (5 bits) defines the number of the tag. The tag can also be longer than 5 bits; this case isn't considered here because it doesn't occur in MMS.

Figure 35: Concrete encoding in ASN.1-BER

The second element (Length) defines the length of the following Content element. The length can be arbitrarily long. If it is longer than 125 octets, two Length-Octets are necessary for the coding. The Content has to be coded as it is indicated in the tag. For the basic types, such as OCTET STRING, the coding of the bits is defined in ISO 8825. The bits on the line are defined as shown in figure 36. There is yet another encoding of the length (indefinite), at which the beginning and the end are determined by an unambiguous handle, respectively.

Figure 36: Bits on the wire in hexadecimal representation

So far, the consideration has viewed the octet string as isolated. Yet very often it is clear in a given context, that the encoded data is of type octet string. Then, the explicit coding of the octet string - as octet string - is not necessary. To this we consider the example in figure 37.

Figure 37: OCTET STRING in a context

We consider the OCTET STRING in a known context now. The Unconstrained Address is defined in the undermost line of the Address definition as third possibility of the CHOICE. The three possibilities are numbered from [0] to [2]. The Unconstrained Address is recognized by the number 2 at the tag.

From the point of view of the MMS syntax, the distinction between the three forms of the Address has the priority. There-fore, the tags [0, 1 and 2] must also be transmitted to enable the correct interpretation for the receiver. ASN.1 now allows, by specifying the keyword IMPLICIT, that the type and the length of the subsequent definition need not be transmitted in addition any more. It is sufficient to code tag [2]. If the receiver recognizes that [2], then it knows the type of the Content element (= OCTET STRING). The [2] corresponds with the type OCTET STRING, the [0] with Unsigned32 and the [1] with Visible String.

The tags [0], [1] and [2] have to be coded as context-specific Tags. The coding is derived in figure 38.

Figure 38: OCTET STRING encoding in a context

The bits on the line coded in the context are shown in figure 39. Even though, as compared with the previous coding (OCTET STRING isolated), more information will be transmitted (namely that it is an Unconstrained Address of the type OCTET STRING), also only seven octets are coded. MMS uses this optimization, wherever it is possible.

Figure 39: Bits on the wire when encoded in the context

Without the implicit coding, both the tag [2] (Unconstrained Address) and the OCTET STRING must be coded explicitly. This coding would - as shown in figure 40 - add two octets and increase the length to nine octets. For this case, the bits on the line are shown in figure 41.

Figure 40: Explicit encoding of an OCTET STRING

Aside from the ASN.1-BER as a flexible encoding rule, the standard ISO 8825 defines the "Canonical Encoding Rules (CER)" and the "Distinguished Encoding Rules (DER)". The DER are particularly advisable for the coding of short messages; the CER are suitable for very long messages. Furthermore, the Packed Encoding Rules (PER) are known as optimal encoding rules. Those ones are not discussed any further here.

Figure 41: Bits on the wire with explicit encoding

It is the task of the Presentation Layer to negotiate the encoding rule to be used with the MMS syntax defined in ASN.1 for the communication during connection set-up.

Example Read Coding

As another example, a MMS Read request is shown here. The definitions aren't resolved any further here because merely the principle shall be shown.

Read-Request ::= SEQUENCE?{
SpecificationWithResult variableAccessSpecification	[0] IMPLICIT BOOLEAN DEFAULT FALSE, [1] VariableAccessSpecification }

The three variables not specified here in detail with the names "feeder205load", "feeder206load", and "feeder-207load" shall be read. The coding of the affiliated Read-Message is as follows:

MMSpdu ::= CHOICE {
A0 42 02 01 04 A4 3D A1 3B A0 39 30 11 A0 0F 80 0D 66 65 65 64 65 72 32 30 35 6C 6F 61 64 30 11 A0 0F 80 0D 66 65 65 64 65 72 32 30 36 6C 6F 61 64 30 11 A0 0F 80 0D 66 65 65 64 65 72 32 30 37 6C 6F 61 64? } }}}	confirmed-RequestPDU [0] IMPLICIT SEQUENCE { invokeID, read [4] SEQUENCE { varaibleAccessSpecification [1], listOfVariable [0] IMPLICIT SEQUENCE OF SEQUENCE { name [0], vmd-specific [0] "feeder205load", name [0] vmd-specific [0] "feeder206load", name [0] vmd-specific [0] "feeder207load"

The bit patterns which result from the coding with BER are listed in the left column. An abstract representation of the Message (Read) is shown on the right. In this application case (read of three variables feeder205load", "feeder206load", and "feeder-207load"), the MMS PDU (Protocol Data Unit) is a sequence of Invoke ID and Read. Because several requests can be on the line simultaneously, they must be distinguished by the Invoke ID. Read contains the list of the three variables (List of Variable) which shall be read. The three names are listed with their scope here.

The bit patterns on the left side will be transmitted as MMS Message. The octets on the very left express something about the type of the transmitted information. The "A0" in the first line says that it is a MMS definition (A = 1010 hex for the first four bits of the ASN.1 types - context-specific and constructed). The "0" is the tag that contains the number in square brackets on the right. The tags distinguish different definitions.

The second column of octets is the length indication. The "42hex" indicates that 66 octets follow. This length indication allows also a syntactic check when receiving the messages because all of the length indications must agree with the actual lengths of the received octets.

6.3 Use of ASN.1 for object modeling

So far the discussion has basically explained the structuring of (typed) MMS variable objects and the representation of the MMS syntax. After we have discussed the encoding on the wire we can return to the abstract level (i.e. independent of the coding) again. Here it is explained exemplarily how applications from the areas:

• Telecontrol according to IEC 60870-5-103 and
• Intercontrol center communication according to IEC 60870-6 TASE.2 of UCA2 (Utility Communication Architecture Version 2)

could be mapped to the MMS object modeling.

Main application of MMS is the data modeling of particularly process data. The latest development of the activities under UCA2 and in the standardization at IEC TC 57 WG 10, 11 and 12 (Substation Automation and Communication) show that the object modeling and the definition of application-oriented objects are prime aspects in the design of future communication systems. Here, several hundred (basic) objects are defined for the communication between station computers and for example protection, control and high voltage equipment.

Object according to IEC 870-5-103 mapped to Named Variable

At first, it is shown here how the data which will be transmitted using the standard IEC 60870-5-103 (information interface for protection devices) could be modeled by MMS. The aim here is to show that MMS is also suitable for the modeling of simple data structures. Doing this, the importance of IEC 60870-5-103 shall not be questioned at all. Aside from the different modeling of the data, MMS of course offers fundamentally more functions for the data exchange (which aren't always needed in simple tele-control applications) than the standard IEC 60870-5-103. Figure 42 shows an example of a so-called ASDU (Time-Tagged Message - Message Number 1 for the Report on Teleprotection Disturbance) according to IEC 60870-5-103. The individual coded fields are explained briefly.

Figure 42: Example of a Message according to IEC 870-5-103

According to what we have learned from MMS till now, this time-tagged Message can be constructed e. g. from individual parts i.e. from MMS Named Types and Named or Unnamed Variables. The ASDU of the type Time-Tagged Message is defined as MMS Named Type Object (here with the corresponding tag):

NAMED-TYPE ::= {
name vmd Specific [0] "ASDU", type Description structure [2] { components?[1] { component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type	[0] "Type Identification", [1] type-ident}, [0] "Cause of Transmission", [1] cot}, [0] "Function Type", [1] fct-Type}, [0] "information Number", [1] info-Number}, [0] "Information Element", [1] dpi}, [0] "Time Stamp", [1] four-Octet-Binary-Time}}}}

The Type Description defines all components of the ASDU. The component types are defined separately, respectively. As an example, the Double Point Information Object is shown (here with the corresponding tag):

dpi NAMED-TYPE ::= {
	name vmdSpecific [0] "DPI", typeDescription integer [5] {
	not-used off  on not-used	(0), (1), (2), (3) }}

For the transmission of data, a MMS variable must be defined according to the Named Type "asdu-1". This can be a Named or an Unnamed Variable. For the transmission various message lengths result, depending on whether one references by name or by address. The messages for the Information Report (comparable IEC 60870-5-103) are represented for both variable types. Figure 43 shows the Information Report with the application of Named Variables. In comparison with the 11 octets of the coding according to IEC 61970-5-103, 39 octets are needed when using the most comfortable MMS modeling. The major part (22 octets) is necessary for the ASN.1 BER. For the contents only 17 octets are necessary.

When applying an Unnamed Variable Object (with the replacement of the name "ASDU_122" by an Address with the value 122 (as index)), the "ASDU" needs only 10 instead of 17 octets. This yields a length of 22 octets.

 

Figure 43: InformationReport from a Named Variable

The fact that the six components (List of Access Result with Type Identification, Cause of Transmission and Time Stamp) aren't coded explicitly but implicitly as Octet String results in a further simplification. This would also correspond to the method of the standard IEC 60870-5-103. Thereby, the Information Report of an Unnamed Variable, as shown in figure 44, is reduced to 22 octets. Of course, the MMS services have remained unchanged in all examples.

 

Figure 44: InformationReport without explicit structures

As the examples above show, the application of the MMS variables, of the ASN.1 description language and of the ASN.1-BER results in a negligible additional need for transmission capacity for the coded data. An additional need by factor two is negligible in regard of the available transmission capacities and the expected higher transmission capacities. This is especially true if one considers that the available transmission bandwidths are generally made use of only to a small extent.

When discussing efficiency, it has to be taken into account also that polling mechanisms, as they are mostly used with solutions according to IEC 60870-5, have a much higher consumption of transmission capacity, because a master permanently polls slaves even if there aren't data. In systems in which data are transmitted only when there are current data, the transmission bandwidth can be considerably smaller than with the shortest coding - even when applying MMS.

Therefore, coding is only one of many influences on the efficiency of communication systems.

Objects according to IEC 870-6 TASE.2 mapped to MMS

The following Named Type Object defines a structure of 12 different components which have a definite meaning in TASE.2 (IEC 61870-6-503, Services and Protocol). A variable of that type can be used to describe an event or time controlled transmission of data from a server to a client. An extensive functionality, which is defined in TASE.2, is hidden "behind" this MMS variable (for further details see article about TASE.2 earlier in this report).

This Named Type Object "DS Transfer Set" (Data Set Transfer Set) is an object of TASE.2. It represents a SCADA (communication) functionality - not application data in the literal sense.

Key Attribute: Type Name = "DS Transfer Set" Attribute: MMS Deletable = FALSE Attribute: Type Description = STRUCTURE {
{component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type {component Name component Type	"Data Set Name" MMS Object Name}, "Start Time" GMT Based S}, "Interval" Time Interval S}, "TLE" Time Interval S, "Buffer Time" Time Interval S}, "Integrity Check" Time Interval S}, "DS Conditions Requested" DS Conditions}, "Block Data" Boolean {TRUE (non-zero), FALSE (0)}}, "Critical" Boolean {TRUE (non-zero), FALSE (0)}}, "RBE" Boolean {TRUE (non-zero), FALSE (0)}}, "Status" Boolean {ENABLED(1), DISABLED(0)}}, "Event Code Requested" Integer16}

For example, the seventh Component Type (= DS Conditions) is represented below without further explanation:

Key Attribute: Type Name = "DS Conditions" Attribute: MMS Deletable = FALSE Attribute: Type Description = BITSTRING{
"Interval Time Out" "Integrity Time Out" "Object Change" "Operator Request" "Other External Event"	bit position 0 bit position 1 bit position 2 bit position 3 bit position 4}