2. History (Introduction to MMS Nr.2)
- In the early 1980s a group of numerical controller (NC) vendors, machine builders and users working under the auspices of committee IE31 of the North-American Electronic Industries Association (EIA) had developed draft standard proposal #1393A titled "User Level Format and Protocol for Bidirectional Transfer of Digitally Encoded Information in a Manufacturing Environment". The situation in manufacturing automation at that time (i.e. the mid 80's) was an industrial tower of Babel. Each area of automation had its own idiosyncratic way of describing things, and variations of terminology among the equipment vendors added to the confusion.
- When the General Motors Corporation began its Manufacturing Automation Protocol (MAP) effort in 1980 they used the EIA-1393A draft standard proposal as the basis for a more generic messaging protocol that could be used for NCs, programmable logic controllers (PLC), robots and other intelligent devices commonly used in a manufacturing environments. The result was the Manufacturing Message Format Standard (MMFS). MMFS was used in the MAP Version 2 specifications published in 1984. During the initial usage of MMFS it became apparent that a more rigorous messaging standard was needed. MMFS allowed too many choices for device and application developers. This resulted in several mostly incompatible dialects of MMFS. Furthermore, MMFS did not provide sufficient functionality to be useful for the Process Control Systems (PCS) found in continuous processing industries. With the objective of developing a generic and non-industry specific messaging system for communications between intelligent manufacturing devices the MMS effort was begun under the auspices of ISO TC 184.
- The result was a standard based upon the Open Systems Interconnection (OSI) networking model called the Manufacturing Message Specification (MMS). A Draft International Standard (DIS) version of MMS was published in December 1986 as ISO DIS 9506. The DIS version of MMS (Version 0) overcame the problems with MMFS but had not yet been advanced to the status of an International Standard (IS). Faced with a publication deadline of November 1988 the MAP technical committees referenced the DIS version of MMS for the MAP V3.0 specification. In December 1988 the IS version of MMS (Version 1) was released as ISO 9506 parts 1 and 2.
- ISO/IEC 9506 (Manufacturing Messaging Specification, MMS) became an standard in 1990; it has been revised for a second edition to be published mid 2000.
2.1. The object modeling approach
- In an attempt to find common ground, the WG2 decided on a strategy of using object modeling techniques to abstract away from all the differences in approaches between these devices. MMS makes use of a formal data modeling technique. Its history illustrates several requirements on data modeling languages and problems in using them. The MMS team created a message standard for an abstract device, allowed specialisations of this abstract message set to apply to each of the device types. Thus, MMS is a multi-part standard; parts 1 and 2 define the core abstract message specification; parts 3 ff. describe specialisations of this model and message specialization for each of several application areas, robots, NC machines, programmable controllers, etc. The revised MMS standard incorporates all common models and services of the former companion standards.
- MMS uses an informal modeling technique, loosely object oriented, but basically an entity-relation method. At the highest level, the communicating node (server) is described as a virtual manufacturing device (VMD). Subordinate to this object, other objects are defined, domains, program invocations, variables, variable lists, semaphores, event conditions, etc. Each such object is described in terms of its attributes, the constraints on the objects because of the attributes values, and the relationships between objects.
- In its area of application, manufacturing automation, there have been many implementations. The unifying language that it developed, that of the VMD and its components, has largely replaced the vendor proprietary languages found in manufacturing automation systems. That is generally speaking, MMS has influenced the human language of communication in manufacturing much more than the computer communications.
2.2. Main objective and use of MMS
- For years the automation of technical processes has been marked by increasing requirements with regard to flexible functionalities for the transparent control and visualization of technical processes. The end-to-end-data exchange of the past will more and more be replaced by systems that connect independent yet coordinated systems - like communications, processing, open and closed loop control, quality protection, monitoring, maintenance, asset management, configuring and archiving systems - to a whole. These individual systems are interconnected and work in a coordinated fashion. As a common component, they require a suitable real-time communication system with adequate functions.
- The MMS standard defines common functions for distributed automation systems. The expression "manufacturing", which stands for the first M in MMS, has been badly chosen. The MMS standard doesn't actually contain any manufacturing specific definitions. The application of MMS is as general as the application of a personal computer. MMS offers a platform for a variety of applications. With the naming UCA, the contents and the application field of this specification get frequently - unconsciously - reduced to applications in the areas of utilities. UCA CASM defines general objects and functions for distributed automation systems - whether for power control, power plant control, production control or in general for automation systems.
- Although a detailed knowledge of MMS is no absolute prerequisite for the understanding of UCA, MMS is explained because the basic approach of the communication is specified in MMS too. There is also a common interest in this standard. MMS offers suitable solutions for many applications with function-related simple requirements. Figure 1 depicts the use of MMS for ICCP (IEC 60870 TASE.2). The connection between the two inner circles represent the MMS communication. The next two layers show how MMS is enhanced by additional functions that make use of MMS. Third the figure shows the standardized objects of IEC 60870-802 on top of the TASE.2 services.
- bild pictures/Image4.gif angepasst!!
- Figure 1: MMS - The basis for the TASE.2
- The figure shows that MMS can be used directly without any additional standard or standard-like specification. Next additional services which make use of MMS objects and services can be specified. As the highest level standardized objects may be used.
- The standard TASE.2 particularly says, that MMS is sufficient for simple applications - if for example only MMS variables and Read, Write and Information Report (spontaneous information) are required. If the requirements go considerably beyond MMS, the use of TASE.2 or UCA CASM becomes relevant. In this case, a shell is laid around MMS (e.g., TASE.2 services and protocols, IEC 60870-6-503) and further communication functions are specified. Other definitions of TASE.2, such as the Indication Points (defined in IEC 60870-6-802, Object Models) and the DataSets (of the TASE.2 Services and Protocols) are directly mapped to MMS variables.
- The TASE.2 objects and services are mapped to MMS completely; therefore a MMS implementation is available in any TASE.2 compliant implementation. This can be used directly by simple applications as shown in figure 1 (access 1).
- Table 1: Comparison TASE.2/MMS
||Yes + bilateral negotiation of objects which should be visible by the partner
|retrieving the self description of the object attributes
|read, write, information report (spontaneous)
|filtering indications and alarms.
||complex reporting model, behaviour can be configured as required by a specific application
|remote configuration of communication behaviour
||remote configuration of relevant object attrributes that define the behaviour.
|data models for process data
||simple and complex data structures for indications, status, measurements, ...
- As shown in table 1 TASE.2 basically distinguishes in two areas from MMS. For reading (MMS Read) and spontaneous information (MMS Information Report) MMS offers all possibilities to send arbitrary typed data. The application programs involved decide under which conditions ("once permanently programmed") the data are being read or reported. These mechanisms for polling (reading) or spontaneous reporting have disadvantages when the data rarely change or if modifications occur in showers. On the other hand, polling at rare modifications leads to unwanted transmissions because almost always the same values/states would be read continuously.
- Spontaneous messages and event showers very easily result in communication overload and overflowing of the receive buffers. A possible remedy would be the cost-intensive increase of the data-rates and of the processor performance. Moreover, these bottlenecks in networked automation systems are even amplified by the variety of the connected devices to - if necessary - only one local network.
- The UCA and TASE.2 offer a demand-driven reporting concept which avoids these bottlenecks and other disadvantages of polling or uncontrollable spontaneous transmission.
2.3. The MMS documents
- The MMS core documents have been jointly published by ISO TC 184 (Industrial Automation) and IEC TC 65 (Process Control Systems) in 1990. Parts 1 and 2 define what is referred to as the "core" of MMS. Part 1 is the service specification.
- The companion standards for special applications followed later.
- The six parts are:
||Comp. Standard for Robots (1992)
||Comp. Standard for Numeric Control (1993)
||Comp. Standard for Programmable Logic Controller (1997)
Comp. Standard for Process Control (1994)
- The service specification contains a definition of
- the Virtual Manufacturing Device,
- the services (or messages) exchanged between nodes on a network, and
- the attributes and parameters associated with the VMD and services.
- Part 2 is the protocol specification. The protocol specification defines the rules of communication:
- the sequencing of messages across the network,
- the format (or encoding) of the messages, and
- the interaction of the MMS layer with the other layers of the communications network.
- The protocol specification utilizes a presentation layer standard called the Abstract Syntax Notation Number One (ASN.1 - ISO 8824) to specify the format of the MMS messages.
- Additions and corrections were published in the meantime. All additions, corrections as well as the objects and services of the companion standards will be published in 2000 as MMS revision. All previous definitions will remain unchanged.
- Today, MMS is being implemented - unlike the practice ten years ago and unlike the supposition still partly found today - on all common communications networks which support transport of data with a certain QoS (Quality of Service). These can be networks like TCP/IP or ISO/OSI on Ethernet, a fieldbus or simple point-to-point connections like HDLC, RS 485 or RS 232. MMS is independent of a seven layer stack. Since MMS was originally developed in the MAP environment (Manufacturing Application Protocols, GM initiative) it was generally believed earlier that MMS could be used only in connection with MAP.
- For years, MMS has been the basis of all the activities of UCA (Utility Communication Architecture). This chapter basically introduces the MMS objects and services which are needed for UCA and for IEC 61850-8-1 (Mapping of ACSI - 61850-7-2 - to MMS).
- MMS provides benefits by lowering the cost of building and using automated systems. In particular, MMS is appropriate for any application that requires a common communications mechanism for performing a diversity of communications functions related to real-time access and distribution of process data and supervisory control. When looking at how the use of a common communications service like MMS can benefit a particular system it is important to evaluate the three major affects of using MMS that can contribute to cost savings:
- Independence, and
- Open Access.
2.4. ISO 9506-1 (part 1) - Service Specification
- Environment and General Management Services
- Two applications that want to communicate with each other can set up, maintain and close a logical connection (initiate, conclude, abort).
- VMD Support
- The VMD itself can be viewed as an object to which all other MMS objects are subordinate (variables, domains, etc. are contained within the VMD). The client can thereby query the status of a Virtual Manufacturing Device (VMD) or the status is reported (Unsolicited Status); the client can query the different lists of the objects (Get Name List), query the attributes of the VMD (Identify) or change the names of objects (Rename).
- Domain Management
- Using a simple flow control (Download, Upload, Delete Domains, ...), programs and data of arbitrary length can be transmitted between client and server and also a third station (and vice versa ). In the case of simple devices, the receiver of the data stream determines the speed of the transmission.
- Program Invocation Management
- Services to create, start, stop and delete modularly structured programs by the client (Start, Stop, Resume, Kill, Delete, ...).
- Variable Access
- This service allows the client to read and write variables that are defined in the server or a server is enabled to report the contents to a client without being requested (Information Report). The structures of these data are simple (octet string) to arbitrarily complex (Structure of Array of ...). In addition, data types and arbitrary variables can be defined (Read, Write, Information Report, Define Variable, ...). The variables consitute the core functionality of every MMS application; therefore the variable access model will be explained in detail below.
- Event Management
- It allows an event-driven operation; i.e. a given service (e. g. Read) is only carried out if a given event has occurred in the server. An alarm strategy is integrated. Alarms will be reported to one or more clients if certain events occur. These have the possibility to acknowledge the alarms later (Define, Alter Event Condition Monitoring, Get Alarm Summary, Event Notification, Acknowledge Event Notification, ...). This model isn't explained further.
- Semaphore Management
- The synchronization of several clients and the coordinated access to the resources of real devices is carried out hereby (Define Semaphore, Take/Relinquish Control, ...). MMS semaphores are named objects that can be used to control access to other resources and objects within the VMD. For instance, a VMD that controls access to a setpoint (a variable) for a control loop could use semaphores to only allow one client at a time to be able to change the setpoint.
- Operator Communication
- Simple services for the communication with operating consoles integrated in the VMD (Input and Output). This model isn't explained further.
- Journal Management
- Several clients can enter data into journals (archives, logbooks) which are defined in the server. Then these data can selectively be retrieved through filters (Write Journal, Read Journal, ...). This model isn't explained further.
- Operator Station Object
- The operator station is an object that represents a means of communicating with the operator of the VMD via a keyboard and display. An Output service is available to display an alpha-numeric string on a text display. An Input service is available to obtain alpha-numeric keyboard input with and without a text prompt on the display.
- An annex of MMS provides a simple set of services for transferring, renaming, and deleting files in a VMD. A FileDirectory service is provided to obtain a list of available files.
2.5. ISO 9506-2 (Part 2) - Protocol Specification
- If a client invokes a service, then the server must be informed about the requested type of the service. For a Read service, e. g. the name of the variables must be sent to the server. This information which the server needs for the execution is exchanged in so-called Protocol Data Units (PDU). The set of all the PDU that can be exchanged between client and server constitute the MMS protocol.
- In other words, the protocol specification - using the standards ISO 8824 (Abstract Syntax Notation One, ASN.1) and 8825 (ASN.1 Basic Encoding Rules, BER) - describes the abstract and concrete syntax of the functions defined in part 1. Examples of the syntax are explained below .
- 2.6. MMS Companion Standards
- The MMS companion standards are only mentioned without any detailed explanation.
- ISO 9506-3 (Part 3) - Companion Standard for Robots
- defines a model of a robot with its different arms and auxiliary equipments. An arm consists for example of path planner, servo mechanism, manipulator, end effector and power supply.
- ISO 9506-4 (Part 4) - Companion Standard for Numerical Control
- models a NC machine with extensions for drill, motorized metal-turning lathe and a flexible manufacturing system. The model of the drill contains a virtual description of a tool magazine with its tool holders, tools inclusive the blades of the tools.
- ISO 9506-5 (Part 5) - Companion Standard for Programmable Controller
- describes a model of a Programmable Logic Controller (PLC). This companion standard contains several classes of communication functions like data access and parameter setting, program management, alarm model, semaphore control and dynamic online-configuring of the communication features.
- The communication-function blocks for MMS services and their mapping to MMS are already integrated in the standard for programmable control (IEC 61131-3 or 61131-5).
- ISO 9506-6 (Part 6) - Companion Standard for Process Control
- specifies features of process control systems. Besides general models for process control and supervision, basic parameters for a function block model are defined.