4. MMS Objects and Services (Introduction to MMS Nr. 4)

MMS defines 15 Classes and some 80 services that operate on these Classes:

List of Objects and Services
Environment and General Management Services
VMD Support
Domain. Represents a loadable resource (e.g. a program) within the VMD.
Program Invocation. A runnable program consisting of one or more domains.
Variable. An element of typed data (e.g. integer, floating point, array, etc.)
Named Variable List. A list of variables that is named as a list.
Event. Objects that represent the state of an event and actions.
Semaphore. An object used to control access to a shared resource.
Operator Station. A "display" and "keyboard" for use by an operator.
Journal. A time based record of events and variables.
File. A file in a filestore or fileserver.

4.1 List of Objects and Services

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:

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

 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):

Object: VMD
Key Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute: Attribute:	Executive Function Vendor Name Model Name Revision Logical Status (STATE-CHANGES-ALLOWED, NO-STATE-CHANGES-ALLOWED, LIMITED-SERVICES-SUPPORTED) List of Capabilities Physical Status (OPERATIONAL, PARTIALLY-OPERATIONAL, INOPERABLE NEEDS-COMMISSIONING) List of Program Invocations List of Domains List of Transaction Objects List of Upload State Machines (ULSM) List of Other VMD-specific Objects

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:

Object: Domain
Key Attribute: Attribute: Attribute: Constraint: Attribute: Attribute: Attribute: Attribute: Attribute: Constraint: Attribute: Attribute: Attribute:	Domain Name List of Capabilities State (LOADING, COMPLETE, INCOMPLETE, READY, IN-USE) State = (LOADING, COMPLETE, INCOMPLETE) Assigned Application Association MMS Deletable Sharable (TRUE, FALSE) Domain Content List of Subordinate Objects State = (IN-USE) 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.

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.

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:

• 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.

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