The first two columns of the table 2 contain the list of all the MMS objects and services of the MMS version 1 from 1990. The third up to the fifth column contain a statement about the application domain of the services (all other services are classified except for the first five services). The services are divided up into three groups:

data acquisition (acquisition of process data and of objects and their parameters) and

manipulation of objects (modifications of attributes of objects).

The fourth column indicates which objects and services are used by TASE.2, the fifth which are used by UCA CASM.

Table 2: MMS objects and services

MMS object

MMS service/operation

1

2

3

4

5

Association

Initiate

x

X

Reject

Conclude

x

X

Abort

x

X

Cancel

VMD

UnsolicitedStatus

X

Status

X

X

GetNameList

X

x

X

Identify

X

X

Rename

X

GetCapabilityList

X

X

Unnamed Variable

Named Variable

Scattered Access

Named Variable List

Named Type

Read

x

x

X

Write

X

x

X

InformationReport

X

x

X

GetVariableAccessAttributes

X

x

X

DefineNamed Variable

x

DefineScatteredAccess

x

GetScatteredAccessAttributes

X

DeleteVariableAccess

X

DefineNamed VariableList

X

x

X

GetNamed VariableListAttributes

X

x

X

DeleteNamed VariableList

X

x

DefineNamedType

X

GetNamedTypeAttributes

X

DeleteNamedType

X

Operator Station

Output

X

Input

X

Semaphore

TakeControl

X

RelinquishControl

X

DefineSemaphore

X

DeleteSemaphore

X

ReportSemaphoreStatus

X

ReportPoolSemaphoreStatus

X

ReportSemaphoreEntryStatus

X

AttachToSemaphore

X

Domain

InitiateDownloadSequence

X

DownloadSegment

X

TerminateDownloadSequence

X

InitiateUploadSequence

X

UploadSegment

X

TerminateUploadSequence

X

RequestDomainDownload

X

RequestDomainUpload

X

LoadDomainContent

X

StoreDomainContent

X

DeleteDomain

X

GetDomainAttributes

X

Program Invocation

CreateProgram Invocation

X

DeleteProgram Invocation

X

Start

X

x

Stop

X

x

Resume

X

x

Reset

X

x

Kill

X

x

GetProgram InvocationAttributes

X

x

Event Condition

Event Action

Event Enrollment

DefineEventCondition

X

DeleteEventCondition

X

GetEventConditionAttributes

X

ReportEventConditionStatus

X

AlterEventConditionMonitoring

X

TriggerEvent

X

DefineEventAction

X

DeleteEventAction

X

GetEventActionAttributes

X

ReportEventActionStatus

X

DefineEventEnrollment

X

x

DeleteEventEnrollment

X

x

AlterEventEnrollment

X

ReportEventEnrollmentStatus

X

GetEventEnrollmentAttributes

X

x

AcknowledgeEventNotification

X

AttachToEventCondition

X

EventNotification

X

x

GetAlarmSummary

X

GetAlarmEnrollmentSummary

X

Journal

Journal Entry

ReadJournal

X

X

WriteJournal

X

X

InitializeJournal

X

X

CreateJournal

X

X

DeleteJournal

X

X

ReportJournalStatus

x

X

4.2 Environment and General Management Services

MMS uses a connection-oriented mode of operation. That is to say, before e. g. a computer can read a value from an IED for the first time, a connection must be set up between the two.

MMS connections have particular quality features such as:

Exclusive allocation of computer and memory resources to a connection. This is necessary to guarantee that all services (for example five Read, ...) that are allowed to be carried out simultaneously find sufficient resources on both sides of the connection,

Flow control in order to avoid blockages and vain transmissions, if e. g. the receive buffers are full,

Segmentation of long messages,

Routing of messages over different networks,

Supervision of the connection if no communication takes place,

Acknowledgment of the transmitted data,

Authentication, access protection (password) and encoding of the messages.

Connections are generally established once and then remain established as long as a device is connected (at least during permanently necessary communication). If, for example, a device is only seldom accessed by a diagnostics system, a connection then doesn't need to be established permanently (waste of resources). It suffices to establish a connection and, later, to close it to release the needed resources again. The connection can remain established for rare but time-critical transmissions. The subordinate layers supervise the connection permanently. Through this the interruption of a connection is quickly recognized.

The MMS services for the connection management are:

initiate (connection set-up).

conclude (orderly connection tear-down, waiting requests are still being answered).

abort (abrupt connection tear-down, waiting requests are deleted).

Besides these services that are all mapped to the subordinate layers, there are two further services:

cancel and

reject.

After the MMS client has sent a Read request to the MMS server, for example, it may happen that the server leaves the service in its request queue and - for whatever reason - does not process it. Using the Service Cancel, the client can now delete the request in the server. On the other hand, it may occur that the server shall carry out a service with "forbidden" parameters. Using Reject it rejects the faulty request and reports this back to the client.

Although MMS was originally developed for ISO/OSI networks a number of implementations are available in the meantime that also use other networks such as the known TCP/IP network. From the point of view of MMS this is insignificant as long as the necessary quality of the connection is guaranteed.

4.3 VMD Support

The VMD object consists of 12 attributes. The Key Attribute identifies the "Executive Function". The Executive function corresponds directly with the entity of a VMD. A VMD is identified by a presentation address):

The attributes Vendor Name, Model Name and Revision inform about the manufacturer and the device.

The Logical status defines, which services may be carried out. The status Limited-Services-Supported allows that only such services may be executed which have read access to the VMD.

The Physical Status indicates whether or not the device works in principle.

The List of Capabilities offers clients and servers a possibility to define application-specific agreements in the form of features. The available memory of a device, for example, could be a capability. Through the Service Get Capability List the current value can be queried. The remaining attributes contain the lists of all the MMS objects available in a VMD. The VMD contains therefore an Object Dictionary in which all objects of a VMD are recorded.

The following services are supported by the VMD:

Services

Description

Unsolicited Status
Status

are used to get the status unsolicited (Unsolicited status) or explicitly requested (Status). Thus, a client can recognize whether a given server - from the point of view of the communication - works at all.

Identify

supplies the VMD attributes Vendor Name, Model Name and Revision. With that, a plausibility check can be carried out from the side of the client.

Get Name List

returns the names of all MMS objects. It can be selectively determined from which classes of objects (for example Named Variable or Event Condition) the names of the stored objects shall be queried. Let's assume a VMD is not yet known to the client till now (because it is, for example, a maintenance device), the client can then browse through the VMD and systematically query all names of the objects. Using the Get services which are defined for every object class (e. g. Get Variable Access Attributes), the client can get detailed knowledge about a given object (for example the Named Variable "T142").

Rename

allows a client to rename the name of an object.

4.4 Domain Management

Domains are to be viewed as containers which represent memory areas. Domain contents can be interchanged between different devices. The object type "domain" with its 12 attributes and 12 direct operations, which create, manipulate, ... delete a domain, are part of the model.

The abstract structure of the domain object consists of the following attributes:

List of Program Invocation References
Upload In Progress
Additional Detail

The Domain Name is an identifier of a domain within a VMD.

Domain Content is a dummy for the information which is within a domain. The contents of the data to be transmitted can be coded transparently or according to certain rules agreed upon before. Using the MMS Revision (2000), the data stream can be coded per default in such a way that a VMD can be transmitted completely - including all MMS object definitions which it contains. This means on the one hand that the contents of a VMD can be loaded from a configuration tool into a device (or saved from a device), and on the other hand that the contents can be stored on a disk per default.

Using a visible string, List of Capabilities describes which resources are to be provided - by the real device - for the domain of a VMD.

MMS Deletable indicates whether or not this domain may be deleted by means of a MMS operation.

Sharable indicates whether or not a domain may be used by more than one program invocation.

List of Program Invocation lists those Program Invocation Objects that use this domain.

List of Subordinate Objects lists those MMS objects (no domains or program invocations) which are defined within this domain: objects which were (a) created by the domain loading, (b) created dynamically by a Program Invocation, (c) created dynamically by MMS operations or (d) created locally.

State describes one of the ten states in which a domain can be.

Upload in Progress indicates whether or not the Domain Content of this domain is being copied to the client at the moment.

MMS defines loading in two directions:

data transmission from the client to the server (download) and

data transmission from the server to the client (upload).

Three phases can be distinguished during loading:

open transmission,

segmented transmission, controlled by the data sink, and

close transmission.

Transmission during download and upload is initiated by the client respectively. If the server initiates, then it has the possibility to initiate the transmission indirectly (see figure 11). For this purpose, the server informs the client that it (the client) shall initiate the loading. Even a third station can initiate the transmission by informing the server which then informs the client.

Figure 11: MMS domain transfer

MMS provides a set of services that allow domains to be uploaded from the device or downloaded to the device. The MMS domain services do not provide for partial uploads or downloads (except as potential error conditions) nor do they provide access to any subordinate objects within the domain. The set of services provided for domains is summarized below:

Services

Description

InitiateDownloadSequence
DownloadSegment
TerminateDownloadSeqence

These services are used to download a domain. The InitiateDownloadSequence service commands the VMD to create a domain and prepare it to receive a download.

InitiateUploadSequence
UploadSegment
TerminateUploadSequence

These services are used to upload the contents of a domain to a MMS client.

DeleteDomain

This service is used by a client to delete an existing domain, usually before initiating a ownload sequence.

GetDomainAttributes

This service is used to obtain the attributes of a domain.

RequestDomainDownload
RequestDomainUpload

These services are used by a VMD to request that a client perform an upload or download of a domain in the VMD.

LoadDomainContent
StoreDomainContent

These services are used to tell a VMD to download (load) or upload (store) a domain from a file. The file may be local to the VMD or may be contained on an external file server.

What is the domain scope?

Further MMS objects can be defined within a domain: variable objects, event objects and semaphore objects. That is to say a domain forms a scope (validity range) in which named MMS objects are reversibly unambiguous.

MMS objects can be defined in three different scopes, as shown in figure 12.

Objects with VMD specific scope (for example the variable "Status_125") can be addressed directly through this name by all clients.

If an object has domain specific scope such as the object "Status_155", then it is identified by two identifiers:

Domain Identifier "Motor_2" and Object Identifier "Status_155".

A third scope is defined by the Application Association. The object "Status_277" is part of the corresponding connection. This object can only be accessed through this connection. When the connection is closed, all objects are deleted in this scope.

Figure 12: VMD- and Domain-Scope

MMS objects can be organized using the different scopes. The object names (with or without domain scope) can be compounded from the following character set:

Identifier ::= VisibleString FROM (

A | a | B | b | C | c | D | d | E | e | F | f |

G | g | H | h | I | i | J | j | K | k | L | l |

M | m | N | n | O | o | P | p | Q | q | R | r |

S | s | T | t | U | u | V | v | W | w | X | x |

Y | y | Z | z | $ | _ | 0 | 1 | 2 | 3 | 4 | 5 |

| 7 | 8 | 9 ) SIZE(1..32

The identifiers can contain 1 to 32 characters and they must not start with a number.

The object names can be structured by agreement in a further standard or other specification. Many standards which reference MMS make much use of this possibility. This way, all named variables with the Prefix "RWE_" and similar prefixes, for example, could describe the membership of the data (in a trans-European information network) to a specific utility of an interconnected operation.

4.5 Program-Invocation-Management

A Program Invocation Object is a dynamic element which corresponds with the program executions in multi-tasking environments. Program Invocations are created by linking several domains. They are either predefined or created dynamically by MMS services or created locally.

A Program Invocation Object is defined by its name, its status (Idle, Starting, Running, Stopping, Stopped, Resuming, Unrunnable), the list of the domains to be used and nine operations.

Program Invocations have a flat structure - though several Program Invocations can reference the same domains (Shared Domains). The contents of the individual domains are absolutely transparent both from the point of view of the domain and from the point of view of the Program Invocations. What is semantically connected with the Program Invocations is outside the scope of MMS. The user of the MMS objects must therefore define the contents; the semantics result from this context. If a Program Invocation connects two domains, then the domain contents must define what these domains shall do together - MMS actually only provides a wrapper.

The Program Invocation Name is a clear identifier of a Program Invocation within a VMD.

State describes the status in which a Program Invocation can be. Altogether seven states are defined.

List of Domains contains the names of the domains which are combined to a Program Invocation. This list also includes such domains which are created by the Program Invocation itself (this can be a domain into which some output is written).

MMS Deletable indicates whether or not this Program Invocation may be deleted by means of a MMS operation.

Reusable indicates whether or not a Program Invocation can be started again after the program execution. If it cannot be started again, then the program Invocation can only be deleted.

Monitor indicates whether or not the Program Invocation reports a transition to the client when exiting the Running status.

Start Argument contains an application specific character string which was transferred to a Program Invocation during the last start operation; this string e. g. could indicate which function has started the program last.

Additional Detail allows the companion standards to make application-specific definitions.

The list of Program Invocation Services follows:

Services

Description

Create Program Invocation

This is used by a client to create a program invocation. This service arranges an operational program, which consists of the indicated domains, in the server. After installation, the Program Invocation is in the status Idle from where it can be started. The monitor and the monitor type indicate, whether or not and how the program invocation shall be monitored.

Delete Program Invocation

Deletable Program Invocations are deleted through this service. Primarily, that is to say that the resources bound to a Program Invocation are released again.

Start

The start service causes the server to transfer the specified Program Invocation from the Idle into the Running state. Further information can be transferred to the VMD through a character string in the start argument. A further parameter (Start Detail) contains once again additional information which can be defined by companion standards.

Stop

The stop service changes a specified Program Invocation from the Running into the Stopped state.

Resume

The Resume service changes a specified Program Invocation from the Stopped into the Running state.

Reset

The Reset service changes a specified Program Invocation from the Running or Stopped into the Idle state.

Kill

The Kill service changes a specified Program Invocation from arbitrary states into the Unrunnable state.

Get Program Invocation Attribute:

Through this service the client can read all attributes of a certain Program Invocation.

4.6 The MMS variable model

Of all the MMS models, the variable model is the most important one. Therefore, it is discussed in detail here.

A real variable is an element of typed data that is contained within a VMD. A MMS variable is a virtual object that represents a mechanism for MMS clients to access the real variable. The distinction between the real variable (which contains the value) and the virtual variable (which represents the access path to the variable) is important. When a MMS variable is deleted, only the access to the variable is deleted, not the actual real variable. When a MMS variable is created it is the access path that is created, not the real variable. MMS defines two types of virtual objects for describing variable access:

4.6.1 The basics of the MMS variable model

The Variable Access Services provide an extensive variable model which offers the user a variety of advanced services for the description and offers the access to arbitrary data of a distributed system.

A wide variety of process data are processed by automation systems. The data, their definition and representation are usually orientated at the technological requirements and at the available automation equipment. The methods the components employ for the representation of their data and the access to them correspond to the way of thinking of their implementers. This has resulted in a wide variety of data representations and access procedures for one and the same technological datum in different components. If e. g. a certain temperature measurement shall be accessed to in different devices, then a huge quantity of internal details must generally be taken into account for every device (request, parameter, coding of the data, ...).

As shown in figure 13, the number of the protocols for the access of a client (on the left in the figure) to the data from n servers (S1 - Sn) can be reduced to a single protocol (on the right in the figure). Through this, the data rate required for the communication primarily in central devices can be reduced drastically.

Figure 12: Unified Protocols

Where exactly is the problem? In programs variables are declared, i.e. they get a name, a type and a value. Described in a simplified way, both the name and the type are converted by the compiler into a memory location and into a reference which is only accessible to the compiled program. Without any further measures, the data of the variable aren't identifiable outside the program. It is concealed for the user of the program how a compiler carries out the translation into the representation of a certain real machine.

The data are stored in different ways depending on the processor; i.e. primarily that the data are stored in various memory locations. During the run-time of the program only this representation is available.

These data aren't visible from the outside. They must first be made visible for the access from the outside. To enable this, an entity must be provided in the implementation of the application. It is insignificant here whether or not this entity is separated from or integrated into the program. This entity is acting for all data which shall be accessible from the outside.

This consideration is helpful to the explanation of the MMS variable model: What do protocols through which process data are accessed have in common? Figure 14 shows the characteristics in principle. On the right is the memory with the real process data which shall be read. The client must be able to identify the data to be read (gray shade). For this purpose, pointer (start address) and length of the data must be known. By means of this information the data can be identified in the memory.

Figure 14: Data access principle

Yet how can a client know the pointer of the data and what the length of the data is? It could have this information somehow and indicate it when reading. Yet if the data should move some time, then the pointer of the data is not correct any more. There can also be the case that the data do not exist at all at the time of reading but must be calculated first. In this case there isn't any pointer. To avoid this, references to the data, which are mapped to the actual pointers (table or algorithm), are used in most cases. In our case, the reference "B" is mapped by table to the corresponding pointer and the length.

The pointer and the length are stored in the type description of the table. The pointer is a system-specific value which generally isn't visible on the outside. The length is dependent on the internal representation of the memory and on the type. An individual bit can for example be stored as an individual bit in the memory or also as a whole octet. However, this is not relevant from the point of view of the communication.

The data themselves and their description are important for the message response of the read service. The question of the external representation (is for example an individual bit encoded as a bit or as an octet?) is - unlike the internal representation - of special importance here! The various receivers of the data must be able to interpret the data unambiguously. For this purpose they need the representation which is a substantial component of the MMS variable model. The data description is therefore derived from the type description.

For the deeper understanding of the variable model three aspects have to be explained more exactly:

objects and their functions,

services (read, write, ...) which access the MMS variable objects,

data description for the transmission of the data.

The object model of a MMS variable object is conceptionally different from a variable according to a programming language. The MMS objects describe the access path to structured data. In this sense, they do not have any variable value.

Access paths

The access path represents an essential feature of the MMS variable model. Starting from a more complex hierarchical structure we will consider the concept. The abstract and extremely simplified example is deliberately chosen. Here, we are merely concerned about the principle.

Certain data of a machine shall be modeled using MMS methods. The machine has a tool magazine with n similar tools. A tool is represented - according to figure 15 - by three components (tool type, number of the blades and remaining use time).

Figure 15: Data of a Machine

The machine with its tool magazine "M" is outlined in the figure on the right. The magazine contains three tools "A", "B" and "C". The appropriate data structure of the magazine is shown on the left. The structure is tree-like; the root "M" is drawn as the topmost small circle (node). "M" has three components (branches) "A", "B" and "C" which are also represented as circles. These components in turn also have three components (branches). In this case, the branches end in a leaf (represented in the form of a square). Leaves represent the end-points of the branches. For each tool, three leaves are shown: "T" (tool type), "A" (number of blades) and "R" (remaining use time). The leaves represent the real data. The nodes ordered hierarchically are merely introduced for reasons of clustering. Leaves can occur at all nodes. A leaf with the information "magazine full/not full" could for example be attached at the topmost node.

With this structure, the MMS features are explained more detailed. The most essential aspect is the definition of the access path. The access to the data (and their use) can be carried out according to various task definitions:

1. selecting all leaves for reading, writing ...,

2. selecting certain leaves for reading, writing ... and

3. selecting all leaves as component of a higher-level structure, for example "machine" with the components magazine "M" and drilling machine,

4. selecting certain leaves as component of a higher-level structure.

Examples of the cases 1. and 2. are shown in figure 16. The case that the complete structure is read is shown in the left top corner (the selected nodes, branches and leaves are represented in bold lines or squares). All nine data are transmitted as response (3 x (T+A+R)). At first, the representation during transmission is deliberately refrained from here and also in the following examples.

Figure 16: Access and partial access

Only a part of the data is read in the top right corner of the figure: Respectively only the leaf "R" of all three components "A", "B" and "C". The notation for the description of the subset M.A.R/.B.R/.C.R is chosen arbitrarily.

The subset M.A.R represents a (access) path which leads from a root to a leaf. It can also be said that one or several paths represent a part of a tree. The read message contains three paths which must be described in the request completely. A path, for example, can also end at "A". All three components of "A" will be transmitted in this case.

Besides the possibility to describe every conceivable subset, MMS also supports the possibility to read several objects "M1" and "M5" in a read request simultaneously (see lower half of figure). Of course, every object can only be partly read too (which is, however, not represented).

An example of case 4 is shown in figure 17 (case 4 has to be understood as the generalization of case 3). Here a new structure was defined using two sub-structures. The object "machine" contains only the "R" component of all six tools of the two magazines "M1" and "M5". The object "machine" shall not be mixed up with a list (Named Variable List ). Read "machine" supplies the six individual "R" values.

Figure 17: "Partial" trees

The component names, such as "A", "B" or "C", need to be unambiguous only below a node - and only at the next lower level. Thus, "R" can always stand for remaining life time. The position in the tree indicates the remaining life time of a particular tool. The new structure "machine" has all features which were described in the previous examples also for "M1" and "M5".

These features of the MMS variable objects can be applied to (1) the definition of new variable objects and (2) the access to existing variable objects. The second case is also interesting. As shown in figure 18, the same result as in figure 17 can be reached by enclosing the description (only the "R" components of the tools shall be read from the two objects "M1" and "M5") in the read request every time. The results (read answer) are absolutely identical in the two cases.

Figure 18: "Partial" trees used for read requests

Every possibility, to assemble hierarchies from other hierarchies (1), or to e. g. read parts of a tree during the access (2), has its useful application. The first case is important in order to avoid enclosing the complete path description every time when reading an extensive part of tree. The second case offers the possibility to construct complex structures based on standardized basic structures (for example the structure of "tool data" consisting of the components "T", "A" and "R") and to use them for the definition of new objects.

Summarizing, it can be stated that the access paths accomplish two tasks:

description of a subset of nodes, branches and leaves of objects during reading, writing, ... and

description of a subset of nodes, branches and leaves of objects during the definition of new objects.

In conclusion, this may again be expressed in the following way: Path descriptions describe the "way" or the "ways" to a single data (leaf) or to several data (leaves). A client can read the structure description (complete tree) through the MMS service Get Variable Access Attributes.

Another aspect is of special importance too. Till now, we have not considered the description of leaves. Every leaf has one of the following MMS basic data types:

BOOLEAN

Booleans are generally represented as a single byte with either a zero (FALSE) or non-zero (TRUE) value. There is no size parameter for Boolean types.

BIT STRING

A Bit String is a sequence of bits. The size of a Bit String indicates the number of bits in the Bit String.

BOOLEAN ARRAY

A Boolean Array is also a sequence of bits where each bit represents TRUE (1) or FALSE (0). Differs from an array of Booleans in that each element in a Boolean Array is represented by a single bit while each element in an array of Booleans is represented by a single byte. The size parameter specifies the number of Booleans (number of bits) in the Boolean Array.

INTEGER

MMS Integers are signed integers. The size parameter specifies the number of bits of the integer.

UNSIGNED

The Unsigned type is identical to the Integer type except that it is not allowed to take on a negative value. Because the most significant bit of an Integer is essentially a sign bit, an Unsigned with a size of 16 bits can only represent 15-bits of values or values of 0 through 32,767.

FLOATING POINT

The MMS definition for floating point is modeled after the IEEE 754 standard but can accommodate any number of bits for the format and exponent width including the single and double precision floating point formats commonly in use today.

REAL

This type is a representation of floating point numbers conforming to the ISO 8824 standard.

OCTET STRING

An Octet String is a sequence of bytes (called an "octet" in ISO terminology) with no constraint on the value of the individual bytes. The size of an Octet String is the number of bytes in the string.

VISIBLE STRING

Unlike the Octet String type, the Visible String type only allows each byte to contain a printable character. Although these character sets are defined by ISO 10646, they are compatible with the common ASCII character set. The size of the Visible String is the number of bytes in the string.

GENERALIZED TIME

This is a representation of time specified by ISO 8824. It provides millisecond resolution of date and time.

BINARY TIME

This is a time format specified by MMS and represents either 1) time of day by a value which is equal to the number of milliseconds from midnight or 2) date and time by a value that is equal to the time of day and the number of days since January 1, 1984.

BCD

Binary Coded Decimal format is where four-bits are used to hold a binary value of a single digit of zero to ten. The size parameter is the number of decimal digits that the BCD value can represent.

OBJECT IDENTIFIER

This is a special class of object defined by ISO 8824 that is used to define network objects.

Every node in a tree is either an array or a structure. Arrays have n elements (0 to n-1) of the same type (this can be a basic type, an array or a structure). When describing a part of a tree, any number of array elements can be selected (e. g. one element, two adjacent elements, two arbitrary elements, ...).

Structures consist of one or several components. Every component can be marked by its position and if necessary by an "Identifier" . the component name. This component name (e. g. "A") is used for the access to a component. Parts of trees can describe every subset of the structure.

The path description contains the following three elements:

All of the possibilities of the description of the structures (individual and composite paths in the type description of the MMS variables) are defined in the form of an extensive abstract syntax.

For every leaf of a structure (these are MMS basic data types), the value range (size) is also defined besides the class. The value range of the class INTEGER can contain one, two or more octets. The value range four (4) octets (often represented as Int32) e. g. indicates that the value cannot exceed these four octets. On the other hand, with ASN.1 BER coding (explained later) and the value range Int32, the decimal value "5" will be transmitted in only one octet (not in 4 octets!). That is to say, only the length needed for the current value will be transmitted.

The aspect of the representation of the data and their structuring during transmission on the line (communication in the original meaning) is dealt with below in the context of the encoding of messages.

The path description is used in a quintuple way (see figure 19):

during the access to and during the definition of variable objects,

in the type description of variable objects,

in the description of data during reading for example,

during the definition of Named Type Objects (an object name of its own is assigned to the type description . i.e. to one or several paths . of those objects) and

when reading the attributes of variables and Named Type Objects

Figure 19: Application of path descriptions

By means of this just acquired knowledge, the models of the MMS variable model are now introduced in more detail.

4.6.2 Objects of the MMS variable model

The five objects of the MMS variable model are:

Description of simple or complex values:

Unnamed Variable,

Named Variable.

List of several unnamed variables or named variables:

Named Variable List,

Scattered Access (is not explained here).

Description of the structure by means of a user-defined name:

Named Type.

4.6.2.1 The Unnamed Variable

The Unnamed Variable Object describes the assignment of an individual MMS variable to a real variable which is located at a definite address in the device. An Unnamed Variable Object can never be created or deleted. The Unnamed Variable has the attributes:

Object:Unnamed Variable

Key Attribute:
Attribute:
Attribute:
Attribute:

Address
MMS Deletable (FALSE)
Access Method (PUBLIC)
Type Description

Address: Address is used to reference the object. There are three different kinds:

a)Numeric Address (non-negative integer values),

b)Symbolic Address (character string),

c)Unconstrained Address (implementation specific format).

Even though in b) the address is represented by character strings, this kind of addressing has absolutely to be distinguished from the Object Name of a Named Variable (see domain scope in the paragraph 10.9 and explanations below).

MMS Deletable: The attribute is always FALSE here.

Access method: The attribute is always PUBLIC here.

Type Description: The attribute points to the inherent abstract type of the subordinate real variable as it is seen by MMS. It specifies the class (bitstring, integer, floating-point etc.), the value range of the values and the group formation of the real variable (arrays of structures). The attribute Type Description is completely independent of the addressing.

Figure 20 represents the Unnamed Variable roughly sketched. The Unnamed Variable with the address "62" (MMSString) has three components with the names: Value, Quality and Time. These component names are only required if individual components (specifying the path, for example "62"/"Value") shall be accessed.

Figure 20: Unnamed Variable Object

MMS Address of the Unnamed Variable

The MMS Address is a system-specific reference which is used by the system for the internal addressing - it is quasi released for the access via MMS. There the address can assume one of three forms (here the ASN.1 notation is deliberately used for the first time):

Address ::= CHOICE {

numericAddress
symbolicAddress
unconstrainedAddress
}

[0] IMPLICIT Unsigned32,
[1] MMSString,
[2] IMPLICIT OCTET STRING

The definition above has to be read as follows: Address defines as (::=) a selection (keyword CHOICE) of three possibilities. The possibilities are numbered here from [0] to [2] to be able to distinguish them. The keyword IMPLICIT is discussed later.

The numeric address is defined as Unsigned32 (4 octet). Thus, the addresses can be defined as an index with a value range of up to 2**32. Since only the actual length (e. g. only one octet for the value 65) will be transmitted for an Unsigned32, the minimal length of the index, which can thus be used, is merely 1 octet. Already 255 objects (of arbitrary complexity!) can be addressed with one octet.

The symbolic address can transmit an arbitrarily long MMSString (for example "DB5_DW6").

The Unconstrained Address represents an arbitrarily long octet string (for example 24FE23F2A1hex). The meaning and the structure of these addresses is outside the scope of the standard.

These addresses can be used in MMS Unnamed Variable and Named Variable Objects and in the corresponding services. MMS can neither define nor change these addresses. The address offers a possibility to reference objects by short indexes.

This service uses the V-Get function to transmit the current value of the real variable, which is described by the Unnamed Variable Object, from a server to a client. Variable Get represents the internal, system-specific function through which an implementation gets the actual data and provides them for the communication.

Write

This service uses the V-Put function to replace the current value of the real variable, which is described by the Unnamed Variable Object, by the enclosed value.

Information Report

As Read, though without prior request by the client. Only the Read.response is sent by the server to the client without being asked. The Information Report corresponds to a spontaneous message. The application itself determines when the transmission is to be activated.

Get Variable Access Attributes

Through this operation, a client can query the attributes of a Unnamed Variable Object.

Explanation of the TypeDescription

Features of the structure description of MMS variable objects were explained in principle above. For those interested in the details, the formal definition of the MMS Type Specification is explained according to figure 21.

The description in ASN.1 was deliberately selected also here. The type specification is a CHOICE (selection) of 15 possibilities (Tags [0] to [13] and [15]). Tags are qualifications of the selected possibility. The first possibility is the specification of an ObjectName, a Named Type Object. If we remember that one Named Type Object describes one or several paths, then the use is obvious. The path description referenced by the name can be used to define a Named Variable Object. Or, if during reading the path must be specified, it can be referenced by a Named Type Object in the server.

The two next possibilities (array and structure) have a common feature. Both refer - through their element type or component type - back to the beginning of the complete definition (type specification). This recursive definition allows the definition of arbitrarily complex structures. Thus, an element of a structure can in turn be a structure or an array.

Arrays are defined by three features. Packed defines whether or not the data are stored optimized. Number-OfElements indicates the number of the elements of the array of equal type (Element Type).

The data of structures can also be saved as packed. Structures consist of a series of components (components [1] IMPLICIT SEQUENCE OF SEQUENCE). This series is marked by the keyword SEQUENCE OF ... which describes a repetition of the following definition. Next in the list is SEQUENCE {component Name und component Type} which describes the individual component. Since the SEQUENCE OF ... (repetition) can be arbitrarily long, the number of the components at a node is also arbitrary.

Then follow the "simple data types". They start at the tag [3]. The length of the types is typical for the simple data types. For example, integers of different lengths can be defined. The length (size) is defined as Unsigned8, which allows for an integer with the length of 255 octets.

It should be mentioned here that - in the ASN.1 description of the MMS syntax - expressions like integer (written in small letters) show that they are replaced by another definition (in this case by the Tag [5] with the IMPLICIT-Unsigned8 definition). Capital letters at the beginning indicate that the definition is terminated here - it isn't replaced any more. It is here a basic definition.

4.6.2.2 The Named Variable

The Named Variable Object describes the assignment of a named MMS variable to a real variable. Only one Named Variable Object should be assigned to a real variable. The attributes of the object are as follows:

Variable Name: The Variable Name unambiguously defines the Named Variable Object in a given scope (VMD specific, domain specific or Application Association specific). The Variable Name can be 32 characters long (plus 32 characters if the object has a domain scope).

MMS Deletable: This attribute shows whether or not the object may be deleted using a service.

Type Description: This attribute describes the abstract type of the subordinate real variable as it represents itself to the external user. This attribute is not inherently in the system unlike the Unnamed Variable Object, i.e. this Type Description can be defined from the outside.

Access method: This attribute contains the information which a device needs to identify the real variable. It contains values which are necessary and adequate to find the memory location. The contents lie outside MMS. A special method, the method PUBLIC, is standardized. The attribute Address is also available in the case of PUBLIC. This is the address which identifies an Unnamed Variable Object. Named Variables can thus be addressed by the name and the ADDRESS (see figure 10.21).

Address: See Unnamed Variable Object. Defining a Named Variable Object does not allocate any memory either, because the real variable must already exist; it is assigned to the Named Variable Object with the corresponding name.

Six operations are defined on the object:

Services

Description

Read

The service uses the V-Get function to retrieve the current value of the real data which is described by the Object.

Write

The service uses the V-Put function to replace the current value of the real data, which is described by the Object, by the enclosed value.

Define Named Variable

This service creates a new Named Variable Object which is assigned to real data.

Get Variable Access Attribute

Through this operation, a client can query the attributes of a Named Variable Object.

Delete Variable Access

This service deletes a Named Variable Object if Attribute Deletable is (=TRUE).

Figure 22 shows the possibilities to reference a Named Variable Object by names, and if it is required, also by Address (optimal access reference of a given system). For a given name, a client can query the Address by means of the service Get Variable Access Attribute.

Figure 22: Address and Variable Name of Named Variable Objects

This possibility allows the access through technological names (Measurement_TIC_13) or with the optimal (index-) address 23 24 hex.

As shown in figure 23, an essential feature of the VMD is the possibility for the client application to define by request Named Variable Objects in the server via the communication. This includes the definition of the name, the type and the structure. The name by which the client would like to reference the Named Variable later is "TIC_42" here. The first component "Value" is of the type Integer32, the second is "Quality" with the values "good" or "bad", the third is "Time" of the type "Time_32". The type of the Data Value Object can be arbitrarily simple (flat) or complex (hierarchical). As a rule, the Data Value Objects are implicitly created by the local configuring or programming of the server (they are pre-defined).

Figure 23: Client defined Named Variable Object

The internal assignment of the variable to the real temperature measurement is made by a system-specific, optimal reference. This reference whose structure and contents are transparent must be known when defining the Named Variable, though. The reference can e. g. be a relative memory address (for example DB5 DW15 of a PLC). So a quick access to the data is allowed.

The Named Variable Object describes how data for the communication are modeled, accessed, encoded and transmitted. What is transmitted, is described independently of the function. From the point of view of the communication, it is not relevant where the data in the server actually come from or where in the client they actually go to and how they are managed - this is deliberately concealed.

4.6.2.3 Named Variable List

The Named Variable List allows the grouping of arbitrary MMS Unnamed Variables, Named Variables and Scattered-Access Objects. Thus, the Named Variable List offers a grouping for the frequently repeated access to several variables (see figure 24). Although the simultaneous access to several MMS variables can be carried out also in a single service (Read or Write), the Named Variable List offers a substantial advantage.

Figure 24: MMS Named Type and Named Variable

When reading several variables in a Read request, the individual names and the internal access parameters (pointers and lengths), corresponding to the names in the request, must be searched for in a server. This search can last for some time in the case of many names or a low processor performance. By using the Named Variable List Object, the search can be cancelled completely - except for the search of a single name (the name of the Named Variable List Object) - if the references, for example, have been entered into the Named Variables on the list system-specifically and thus optimally. Once the name of the list has been found, the appropriate data can be provided quickly.

Thus, the Named Variable List Object provides optimal access features for the applications. This object class is used in the known applications of MMS very intensively.

Variable List Name: The Variable List Name unambiguously identifies the Named Variable List Object in a given scope (VMD specific, domain specific or Application Association specific). See also MMS Object Names above.

MMS Deletable: This attribute shows whether or not the object may be deleted.

List of Variable: A list can contain an arbitrary number of objects (Unnamed Variable, Named Variable or Scattered-Access Object).

Kind of Reference: Lists can refer to three object classes: Named Variables, Unnamed Variables and Scattered Access; no Named Variable Lists can be included.

Reference: An optimal internal reference to the actual data is assigned to every element of the list. If a referenced object is not (any more) available, the entry into the list will indicate it. When accessing the list, for example by Read, no data but an error indication will be transmitted to the client for this element.

Access Description: In the same way as for the access of a variable - e. g. in the request during Read - could be defined that only parts (part of a tree) of a variable shall be read, can this also be applied to every element of the Named Variable List.

The following services are defined:

Services

Description

Read

This service reads the data of all objects being part of the list (Unnamed Variable, Named Variable and Scattered Access Object). For objects which are not defined an error is reported in the corresponding place of the list of the returned values.

Write

This service writes the data from the write request into the objects being part of the list (Unnamed Variable, Named Variable and Scattered Access Object). For objects which are not defined an error is reported in the corresponding place of the list of the returned values.

Information Report

As the Read service; as if the read data were sent by the server to the client without prior request (Read Request) by the client, i.e. as if only a Read Response would be transmitted.

Define Named Variable List

Using this service a client can create a Named Variable List Object.

Get Named Variable List Attributes

This service queries the attributes of a Named Variable List Object.

Delete Named Variable List

This service deletes the specified Named Variable List Object.

4.6.2.4 Scattered Access Object

The Scattered Access Object also represents a list of MMS objects. The object has the following structure:

This is the same structure the Named Variable List Object has. However, the Kind of Reference has another meaning.

Kind of Reference: Lists can reference three object classes: Named Variables, Unnamed Variables and Scattered Access. Scattered Access Objects can therefore contain other Scattered Access Objects, that is to say the definition is recursive.

Fundamental differences to the Named Variable Lists also exist regarding the access. When accessing the individual components of a Named Variable List Object, the components are independent from each other. If a component is not defined for example, then - when reading - the data of the other components will be transmitted to the client. The Scattered Access Object behaves in such a way that - for example after a read request - no response data are sent to the client if a component is not available. This way it is achieved that all or no data will be transmitted. Thus only consistent data records are sent.

4.6.2.5 The Named Type Object

The Named Type Object merely describes structures. The object model is very simple:

Object: Named Type

Key Attribute:
Attribute:
Attribute:

Type Name
MMS Deletable (TRUE, FALSE)
Type Description

Essential attribute of a variable object is the Type Description, which was already discussed before for Named and Unnamed Variables. On the one hand, TASE.2 or UCA standard data structures can be specified by means of Named Types. This is the most frequent application of the Named Type Objects. On the other hand, Named Types can be used for the access to the server. The read request can refer to a Named Type Object. Or the Named Type Object will be used to define Named Variables.

Figure 25 describes the application of the Named Type Objects for the definition of a Named Variable. A variable will be created by the request Define Named Variable.

Figure 25: Inheritance of Type of the MMS NamedType Objects

It shall have the name "TIC_42", the address 22 31 hex and the type that is defined in the Named Type Object "MWert". The variable inherits the type from the Named Type Object. The inheritance has the consequence that the variable will only have the type but not the name of the Named Type Object. This inheritance was defined so strictly in order to avoid that through deleting the Named Type the type of the variable would get undefined or that by subsequent definition of a differently structured Named Type with the old type name "MWert" the type of the variable would be changed (the Named Type Object and with that the new Type Description would be referenced by the old name).

Perhaps it is objected now that this strict inheritance has the consequence that also the type would have to be saved for each variable (even though many variables have the same Type Description). Since these variables can internally be implemented in a system in whatever way the implementers likes it, they can refer through an internal index to a single (!) type description. He must only make sure that this type description is not deleted. If the accompanying Named Type Object gets deleted, then the referenced type description must remain preserved for these many variables.

The disadvantage that the name of the "structure mother" , i.e. the Named Type, is not known any more as an attribute of the variables has been eliminated in the MMS Revision.

use the Type Description of the Named Type Object when carrying out their tasks.

4.7 Event Management Model

The MMS Event Management Model has not been applied by UCA version 2 (1999). A brief description is introduced here just for general purpose.

In a real sense an event, or an alarm, is easy to define. Most people have an intuitive feel for what can comprise an event within their own area of expertise. For instance, in a process control application it is common for a control system to generate an alarm when the process variable (e.g. temperature) exceeds a certain preset limit called the high alarm threshold. In a power distribution application an alarm might be generated when the difference in the phase angle of the current and voltage waveforms of a power line exceeds a certain number of degrees. The MMS event management model provides a framework for accessing and managing the network communication aspects of these kinds of events. This is accomplished by defining three named objects that represent 1) the state of an event (event condition), 2) who to notify about the occurrence of an event (event enrollment) and 3) the action that the VMD should take upon the occurrence of an event (event action).

For many applications, the communication of alarms can be implemented by using MMS services other than the event management services. For instance, a simple system can notify a MMS client about the fact that a process variable has exceeded some preset limit by sending the process variable's value to a MMS client using the InformationReport service. Other schemes using other MMS services are also possible. When the application is more complex and requires a more rigorous definition of the event environment in order to ensure interoperability, the MMS event management model should be used.

4.7.1 Event Condition Object

A MMS event condition object is a named object that represents the current state of some real condition within the VMD. It is important to note that MMS does not define the VMD action (or programming) that causes a change in state of the event condition. In the process control example given above, an event condition might reflect an IDLE state for when the process variable was not exceeding the value of the high alarm threshold and an ACTIVE state when the process variable did exceed the limit. MMS does not explicitly define the mapping between the high alarm limit and the state of the event condition. Even if the high alarm limit is represented by a MMS variable, MMS does not define the necessary configuration or programming needed to create the mapping between the high alarm limit and the state of the event condition. From the MMS point of view, the change in state of the event condition is caused by some autonomous action on the part of the VMD that is not defined by MMS.

A network triggered event condition is triggered when a MMS client specifically triggers it using the TriggerEvent service request. Network triggered events do not have a state (their state is always DISABLED). They are useful for allowing a MMS client to control the execution of event actions and the notifications of event enrollments.

Monitored

A monitored event condition has a state attribute that the VMD sets based upon some local autonomous action. Monitored event conditions can have a Boolean variable associated with them that is used by the VMD to evaluate the state. The VMD periodically evaluates this variable. If the variable is evaluated as TRUE, the VMD sets the event condition state to ACTIVE. When the Boolean variable is evaluated as FALSE, the VMD sets the event condition state to IDLE. Event conditions that are created as a result of a CreateProgramInvocation request with the Monitored attribute TRUE, are monitored event conditions but they do not have an associated Boolean variable.

4.7.2 Event Actions

An event action is a named MMS object that represents the action that the VMD will take when the state of an event condition changes. An event action is optional. When omitted, the VMD would execute its event notification procedures without processing an event action. An event action, when used, is always defined as a confirmed MMS service request. The event action is attached or linked with an event condition when an event enrollment is defined. For example, an event action might be a MMS Read request. If this event action is attached to an event condition (by being referenced in an event enrollment), when the event condition changes state and the event condition is enabled, the VMD would execute this Read service request just as if it had been received from a client. Except that the Read response (either positive or negative) is included in the EventNotification service request that is sent to the MMS client defined for the event enrollment. A confirmed service request must be used (i.e. Start, Stop, Read, etc.). Unconfirmed services (e.g. InformationReport, UnsolicitedStatus, and EventNotification) and other services that must be used in conjunction with other services (e.g. domain upload-download sequences) cannot be used as event actions. In addition to its name, an event action has the following attributes:

4.7.3 Event Enrollments

The event enrollment is an named MMS object that ties all the elements of the MMS event management model together. The event enrollment represents a request on the part of a MMS client to be notified about changes in state of an event condition. When an event enrollment is defined, references are made to an event condition, an event action (optionally) and the MMS client to which EventNotification should be sent.

4.8 Semaphore Management Model

The Semaphore Management Model is not used by UCA version 2 (1999) and by the drafts IEC 61850-8-1 (Mapping of ACSI to MMS).

In many real-time systems there is a need for a mechanism by which an application can control access to a system resource. An example might be a workspace that is physically accessible to several robots. Some means to control which robot (or robots) can access the workspace is needed. MMS defines two types of semaphores for these types of applications: 1) Token Semaphores and 2) Pool Semaphores.

A token semaphore is a named MMS object that can be a representation of some resource within the control of the VMD to which access must be controlled. A token semaphore is modeled as a collection of tokens that MMS clients take and relinquish control of using MMS services. This allows both multiple or exclusive ownership of the semaphore. When a MMS client owns the token, it provides some level of access to the underlying resource. An example might be where two users want to change a setpoint for the same control loop at the same time. These users could use a MMS token semaphore containing only one token to represent the control loop in order to coordinate their access to the setpoint. When the user "owns" the token, they can change the setpoint. The other would have to wait until ownership is relinquished.

A token semaphore can also be used for the sole purpose of coordinating the activities of two MMS clients without representing any real resource. This kind of "virtual" token semaphore looks and behaves the same except that they can be created and deleted by MMS clients using the DefineSemaphore service.

4.9 Operator Stations

An operator station is a MMS object that can be used to represent character based input and output devices that may to attached to the VMD for the purpose of communicating with an operator local to the VMD.

MMS defines three types of operator stations:

Entry

An entry only operator station consists of an input device only. This may be a keyboard or perhaps a bar code reader. The input data must be of the type Visible String consisting of alpha-numeric characters only.

Display

A display only operator station consists of a character based output display that can display Visible String data (no graphics or control characters).

Entry-Display

This type of operator stations consists of both a entry station and a display station.

Because the operator station is a representation of a physical feature of the VMD, it exists beyond the scope of any domain or application association. Therefore, MMS clients access the operator station by name without scope. MMS allows for any number of operator stations for a given VMD.

4.10 Journals

The Journals Management Model is not used by UCA version 2 (1999) and by the drafts IEC 61850-8-1 (Mapping of ACSI to MMS) for the logging model.

A MMS journal represents a log file that contains a collection of records (called journal entries) that are organized by time stamps. Journals are used to store time based records of tagged variable data, user generated comments or combination of events and tagged variable data. Journal entries contain a time stamp that indicates when the data in the entry was produced (not when the journal entry was made). This allows MMS journals to be used for applications where a sample of a manufactured product is taken at one time, analyzed in a laboratory off-line, and then at a later time placed into the journal. In this case the journal entry time stamp would indicate when the sample was taken.

MMS clients read the journal entries by specifying the name of the journal (which can be VMD-Specific or AA-Specific only) and either 1) the date/time range of entries that the client wishes to read or 2) by referring to the entry ID of a particular entry. The entry ID is a unique binary identifier assigned by the VMD to the journal entry when it is placed into the journal.

Each entry in a journal can be one of the following types:

Annotation

This type of entry contains a textual comment. This is typically used to enter a comment regarding some event or condition that had occurred in the system.

Data

This type of entry would contain a list of variable tags and the data associated with those tags at the time indicated by the time stamp. Each variable tag is a 32-character name that does not necessarily refer to a MMS variable (although it might).

Event-Data

This type of entry contains both variable tag data and event data. Each entry of this type would include the same list of variable tags and associated data as described above along with a single event condition name and the state of that event condition at the time indicated by the time stamp.

The services available for MMS journals are as follows:

Services

Description

ReadJournal

This service is used by a client to read one or more entries from a journal.

WriteJournal

This service is used by a client to create new journal entries in a journal. A journal entry can also be created by local autonomous action by the VMD without a client using the WriteJournal service.

CreateJournal
DeleteJournal

These services are used by a client to create and delete (if the journal is deletable) journal objects. The CreateJournal service only creates the journal. It does not create any journal entries (see ReadJournal).

InitializeJournal

This service is used by a client to delete all or some of the journal entries that are in a journal. For instance, a client can use InitializeJournal to delete old journal entries that are no longer of any interest.

4.11 Files

MMS also provides a set of simple file transfer services for devices that have a local file store but do not support a full set of file services via some other means. For instance, many robot implementations of MMS use the file services for moving program (domain) files to the robot from a client application. The MMS file services support file transfer only, not file access. Although these file services are defined in an annex within the MMS standard, they are widely supported by most commercial MMS implementations.

The services for files are described below:

Services

Description

FileOpen

This service is used by a client to tell the VMD to open a file and prepare it for a transfer.

FileRead

This service is used to obtain a segment of the file's data from a VMD. The client would continue to issue FileOpen requests until the VMD indicates that all the data in the file has been returned. The number of bytes returned in each FileRead response is determined solely by the VMD (and can vary from one FileRead response to the next) and is not controllable by the client.

FileClose

This service is used by a client to close a previously opened file. It is used after all the data from the file has been read or can be used to discontinue a file transfer before it is completed.

ObtainFile

This service is used by a client to tell the VMD to obtain a file. When a VMD receives an ObtainFile request it would issue FileOpen, FileRead(s) and FileClose service requests to the client application that issued the ObtainFile request. The client would then have to support the server functions of the FileOpen, FileRead, and FileClose services. A third party option is available (if supported by the VMD) to tell the VMD to obtain the file from another node on the network using some protocol (which may or may not be MMS).

FileRename
FileDelete
FileDirectory

These services are used to rename, delete, and obtain a directory of files on the VMD respectively.