MMS Protocol
Introduction
MMS (Manufacturing Message Specification) serves as a messaging system crucial for modeling real devices and their functions. It facilitates the exchange of information, including process data and supervisory control information, between networked devices and computer applications, all within real-time conditions.
MMS is defined by ISO/IEC 9506-1 (Services) and ISO/IEC 9506-2 (Protocol) standards.
The service specification within MMS outlines the Virtual Manufacturing Device (VMD), detailing services and messages exchanged between network nodes, along with attributes and parameters associated with the VMD and services.
On the other hand, the protocol specification manages communication rules. It includes how messages move in the network, how they are formatted and encoded, and how the MMS layer interacts with other network layers..
MMS operates using a client-server model. The client, like a monitoring system or a control center, requests data or actions from the server. The server, which hosts a Virtual Manufacturing Device (VMD) and its objects (like variables), responds to these requests. The VMD acts as a container holding all other objects, creating a structured hierarchy for organizing and accessing different data and functions within the MMS system. This back-and-forth between client and server enables MMS service requests and responses, ensuring smooth communication between devices and applications.
MMS uses an object-oriented approach with object classes (Named Variable, Domain, Program invocation), instances and methods (read, write, store, start, stop, etc.).
MMS defines a range of objects commonly present in typical devices. Each of these objects is associated with corresponding services, as defined in the ISO 9506-2 standard. The table below demonstrates the mapping of MMS objects to their counterparts in IEC 61850, specifically outlined in IEC 61850-7-2.
MMS communication types
The MMS protocol, as outlined in ISO 9506 [9], implements two distinct types of communications:
Confirmed MMS Services:
Confirmed MMS services are initiated using the Confirmed-Request PDU, incorporating a request service (refer to Appendix J). ISO 9506 specifies 87 different services, such as getNameList, read, write, and getVariableAccessAttributes.
Each Confirmed-Request PDU is validated by either a Confirmed-Response PDU or a Confirmed-Error PDU.
Moreover, a Confirmed-Request PDU can be halted by a Cancel-Request PDU, confirmed through a Cancel-Response PDU or a Cancel-Error PDU.
Correlation between each Request PDU and its corresponding Response PDU is established via the InvokeID, a 32-bit unsigned integer.
Unconfirmed MMS Services:
Unconfirmed MMS services do not elicit a response PDU or an error PDU. Additionally, there's no provision for canceling an unconfirmed MMS service.
The standard defines three distinct unconfirmed services: informationReport, unsolicitedStatus, and eventNotification. These services operate without necessitating a specific response or error confirmation.
MMS data transfer
The backbone of MMS communication largely relies on confirmed-Request and confirmed-Response messages. The confirmed-Request Protocol Data Unit (PDU) encapsulates an InvokeID, a unique identifier ensuring request clarity, and specifies the type of ConfirmedServiceRequest, such as status, getNameList, read, write, and others. Each service carries distinct data based on the nature of the request.
Data transfer in MMS typically occurs in two phases:
Dataset Initialization: In this phase, clients initiate requests for information regarding available logical nodes, datasets, variables, and attributes. Services like getNameList, getVariableListAttributes, getNamedVariableListAttributes, etc., are employed to acquire this dataset-related information.
Data Access: Following initialization, the focus shifts to data manipulation. Once the dataset is initialized, data objects become accessible for operations such as reading, writing, and other related functions. This phase involves direct interaction with the identified data objects to perform necessary actions and retrieve information.
These two distinct phases, initialization, and subsequent data access, delineate the process flow within MMS communication, allowing for structured and systematic data interaction and management between communicating entities.
The presented figure illustrates a sample instance of MMS communication within the framework of IEC 61850.
MMS Encapsulation
It appears that the MMS (Manufacturing Message Specification) lacks a specification for directly addressing clients and servers, relying instead on the addressing scheme provided by the underlying protocols. In practical implementations, clients and servers are typically identified using their IP addresses, and MMS data is transmitted over TCP utilizing port 102. However, it's worth noting that port 102 is specifically designated for ISO TSAP (Transport Service Access Point) Class 0, which serves as a general encapsulation mechanism for ISO model protocols over TCP.
Within this encapsulation, various ISO protocols are included as part of the ISO stack, although not all of these protocols are necessarily present in every MMS message. These protocols encompass different layers of the ISO OSI (Open Systems Interconnection) model, and their use may vary depending on the specifics of the message being transmitted. Each of these encapsulation protocols plays a role in the transmission and organization of MMS data, contributing to the comprehensive structure of the ISO stack.
Mapping IEC 61850 objects and services to MMS
The table below outlines the ASCI (Abstract Communication Service Interface) objects and services as defined in IEC 61850-7-2, mapping them to their corresponding MMS (Manufacturing Message Specification) services according to IEC 61850-8-1.