The difficulty of communication between industrial systems can become a high-cost problem. Each new integration requires custom development, extensive testing, and continuous maintenance. Dedicated drivers must be created, variables mapped manually, and every failure scenario validated. The result is: increased lead times, rising costs, and greater operational risks.
This is how ISO 9506, known as MMS (Manufacturing Message Specification), gained relevance. Originally developed by General Motors to solve problems in automated manufacturing environments, MMS introduced a structured communication model for industrial automation.
Instead of merely exchanging registers or memory blocks without context, MMS began treating information as organized objects (variables, domains, lists, and programs) accessible through standardized services. Its structure based on the OSI model and its independence from the physical medium allowed for application across different network infrastructures.
In the power sector, its importance is becoming even more evident. IEC 61850 utilizes the MMS protocol for communication between intelligent electronic devices (IEDs) in substations to enable the exchange of information in critical operations with predictability and consistency. Learn about this protocol in this article.
The Origin of ISO 9506
At the beginning of the digital era in factories, if a plant installed a Brand A controller, it would have to use sensors and software from that same brand due to the proprietary and closed communication protocol. This phenomenon, known as protocol lock-in, limited innovation and increased costs, creating islands that did not exchange information with one another.
ISO 9506 emerged as an effort to standardize this communication. Originally published in 1990, it was not designed just to move bits and bytes, but to provide a real-time messaging system capable of transferring process data and supervisory control information between networked devices transparently. Unlike protocols of the time, such as Modbus, which focused on raw memory addresses, MMS defines a model where a machine’s physical resources are represented as logical objects. This enables the supervisory system to not need to know exactly at which memory address a piece of data is located, but rather what the “name” and “type” of the object it wishes to access are.
This shift was the first real step toward the integration between Operational Technology (OT) and Information Technology (IT), enabling devices from different manufacturers to communicate efficiently.
The VMD Architecture
At the core of the MMS protocol lies a fundamental concept: the Virtual Manufacturing Device (VMD). The VMD acts as a digital “avatar” of the physical machine, hiding the manufacturer’s hardware-specific complexities and presenting a standardized interface of objects and services.
In this way, client applications interact with a structured model without needing internal details of the physical implementation, favoring interoperability and portability between devices.
In a traditional architecture, the operator needed to know exactly that the temperature was located, for example, in register 40001 of that specific PLC. This dependence on fixed addressing made integration rigid.
With MMS, the logic changes completely. Instead of accessing a numerical address, the system can simply request the value of the object named “Temperature” from the VMD. The VMD is responsible for translating this request into the machine’s internal language and returning the requested information.
It is precisely this object-oriented model that sustains interoperability. Should the PLC be replaced by one from another manufacturer, the system will continue to operate normally as long as the new VMD makes the same “Temperature” object available. The application remains unchanged because the logical interface remains consistent.
VMD object structure
VMD object structure The MMS protocol defines a series of standard objects that must exist in each device to facilitate reading, writing, and event signaling operations. Below, we detail the main components that form this structure:
| MMS Object | Description | Function |
| VMD (Virtual Manufacturing Device) | The primary object that encapsulates all other device resources. | Represents the physical device on the network (e.g., a robot or a relay). |
| Variables | Process data, such as states, measurements, and setpoints. | Monitor system pressure or the on/off state. |
| Domains | Memory areas that can contain programs or large data blocks. | Download new control logic to the machine. |
| Journals | Chronological logs of events, alarms, and status changes. | Fault auditing and historical traceability of critical events. |
| Files | Locally stored data structures on the device. | Transfer fault logs or SCL configuration files. |
This organization enables MMS to support different types of devices, from simple sensors to complex machines, while maintaining communication transparency.
The Client/Server Model
To ensure that communication occurs without failures in hostile environments, such as substations or production lines, MMS utilizes the classic client-server model, but with a superior layer of robustness.
In this model, the Client is typically a higher-level system, such as a SCADA (Supervisory System), a gateway, or an MES (Manufacturing Execution System). The client is the one that requests information or sends control commands. Meanwhile, the Server is the device, such as a PLC, an intelligent electronic device (IED), or a sensor, that holds the data and executes the requested actions.
Unlike broadcast-based protocols (where information is blasted onto the network without confirmation), MMS operates through a strict request and response mechanism. When the client requests an action, such as writing a value to a variable, the server processes the request and sends a response confirming whether the operation was successfully executed or detailing the reason for a failure. This constant feedback is what makes MMS ideal for critical applications.
MMS Protocol Services
The ISO 9506-1 standard defines a wide range of services that allow the client to interact with the server’s data model. These services are categorized to meet different operational needs, from real-time monitoring to remote device maintenance:
- – Variable access and process monitoring: The most common service is variable access, which allows the reading and writing of individual data points or datasets. Through Read and Write services, the client can obtain the current state of a machine or change operating parameters in real time. Additionally, MMS supports the definition of variable lists, enabling the client to request multiple pieces of data in a single message.
- – Event and alarm management: One of the major differentiators of MMS is its native ability to handle events. Instead of the client needing to constantly ask the server, “Has an error occurred?”, MMS allows for the configuration of event reports. When a specific condition occurs (e.g., a temperature exceeds a limit), the MMS server generates an automatic notification, builds a dataset representing the change, and sends it via a report, which can be configured for immediate or buffered transmission.
- – File transfer and logic management: For the maintenance of industrial systems, MMS offers file management services. This allows the upload or download of configuration files and event logs directly through the communication protocol. This feature eliminates the need for dedicated programming cables or physical access to the devices.
MMS vs. Modbus vs. OPC UA
For the industrial manager who needs to decide which technology to adopt, it is vital to understand the positioning of MMS in relation to other giants of industrial communication.
| Feature | Modbus (TCP/RTU) | MMS | OPC UA |
| Architecture | Master-Slave (RTU) / Client-Server (TCP) | Client-Server (Objects) | Client-Server / Pub-Sub |
| Data | Raw numerical registers | Structured Virtual Objects (VMD) | Rich semantic information models |
| Ease of use | Very simple and straightforward | Requires detailed configuration (SCL) | High implementation complexity |
| Security | Non-native (depends on TLS/VPN) | Robust via IEC 62351 | Integrated (Encryption and Certificates) |
| Applications | Basic automation and simple devices | Energy, Critical Manufacturing, and IEDs | IT/OT Integration and Industry 4.0 |
| Exchange Mechanism | Constant Polling (Request-Response) | Event-Based and Automatic Reports | Report on Change and Subscriptions |
Modbus remains one of the most widely used protocols in the industry, primarily due to its structural simplicity and ease of implementation. However, its architecture limits the handling of structured data and offers restricted features in terms of security.
OPC UA, in turn, represents an approach oriented toward high connectivity, the cloud, and IIoT. With a robust data model and native security mechanisms, it provides greater flexibility and interoperability. On the other hand, this sophistication can imply higher implementation complexity.
Meanwhile, MMS stands out as a strategic solution for real-time control of critical infrastructures, particularly in environments that demand compliance with international standards such as IEC 61850 with high robustness.
Integration in MasterTool v 3.77
In our continuous commitment to innovation, we announce that the MMS protocol is now fully integrated into our programming and configuration software, MasterTool IEC XE, starting from version 3.77.
MasterTool is already known for being a comprehensive tool for programming, debugging, and simulating applications based on the IEC 61131-3 standard. With the inclusion of native MMS support, we have eliminated several significant engineering barriers:
- – Native configuration of MMS servers: It is now possible to configure HX Series CPUs (Xtorm) as MMS servers directly within the MasterTool environment.
- – Facilitated object mapping: The new version allows the user to select variables from their project and transform them into MMS objects (VMD) intuitively, without the need for external tools.
- – Support for the power sector: This integration reinforces the capacity of Altus CPUs to act as IEDs in substation automation projects following the IEC 61850 standard, enabling the sending of MMS messages and reports in a synchronized manner.
- – Faster diagnostics: The protocol integration in version 3.77 allows the operator to visualize MMS message traffic and quickly identify communication issues.
Download MasterTool version 3.77 by clicking here
The industry of the future will not be defined only by the power of its machines, but by the clarity and speed with which they can communicate. Integrated into Altus solutions, this protocol establishes a solid foundation for machine interoperability, operational robustness, and technological longevity.
