(c) Copyright 1994. Ralph Mackiewicz. All Rights Reserved. Permission is hereby granted by the author for any individual or educational institution to copy and distribute this document freely provided that 1) the document, or any copy thereof, is not used for commercial purposes, 2) is not copied, used or distributed by a commercial organization or company, and 3) that appropriate credit (including the copyright notice) be given in all reproductions and any other usage. Other rights may be granted by written permission of the author.
DISCLAIMER: This document is provided "as is" without warranty of any kind. While the information contained herein is thought to be accurate at the time of publication, the author accepts no liability or responsibility of any kind for any use of this document.
MMS (Manufacturing Message Specification) is an internationally standardized messaging system for exchanging real-time data and supervisory control information between networked devices and/or computer applications in a manner that is independent of: 1) the application function being performed or 2) the developer of the device or application. MMS is an international standard (ISO 9506) that is developed and maintained by Technical Committee Number 184 (TC184), Industrial Automation, of the International Organization for Standardization (ISO).
The messaging services provided by MMS are generic enough to be appropriate for a wide variety of devices, applications, and industries. For instance, the MMS Read service allows an application or device to read a variable from another application or device. Whether the device is a Programmable Logic Controller (PLC) or a robot, the MMS services and messages are identical. Similarly, applications as diverse as material handling, fault annunciation, energy management, electrical power distribution control, inventory control, and deep space antenna positioning in industries as varied as automotive, aerospace, petro-chemical, electric utility, office machinery and space exploration have put MMS to useful work.
In the early 1980s a group of numerical controller (NC) vendors, machine builders and users working under the auspices of committee IE31 of the 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". 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 Technical Committee Number 184, Industrial Automation, of the International Organization for Standardization (ISO).
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. It was not until after the development of backwards compatibility agreements by the National Institute of Standards and Technology (NIST) that the IS version of MMS was referenced by the MAP V3.0 specifications.
The MMS standard (ISO 9506) is jointly managed by Technical Committee Number 184, Industrial Automation, of ISO and the International Electrotechnical Commission (IEC) and consists of two or more parts (see "Companion Standards"). Parts 1 and 2 define what is referred to as the "core" of MMS. Part 1 is the service specification. The service specification contains a definition of 1) the Virtual Manufacturing Device, 2) the services (or messages) exchanged between nodes on a network, and 3) the attributes and parameters associated with the VMD and services. Part 2 is the protocol specification. The protocol specification defines the rules of communication which includes 1) the sequencing of messages across the network, 2) the format (or encoding) of the messages, and 3) 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.
MMS provides a rich set of services for peer-to-peer real-time communications over a network. MMS has been used as a communication protocol for many common industrial control devices like CNCs, PLCs, robots. There are MMS applications in the electrical utility industry such as in Remote Terminal Units (RTU), Energy Management Systems (EMS) and other Intelligent Electronic Devices (IED) like reclosers and switches. Most popular computing platforms have MMS connectivity available either from the computer manufacturer or via a third party. Some of the computer applications available include Application Programming Interfaces (API), graphical monitoring systems, gateways, and drivers for spreadsheets, word processors, Application Enablers (A/Es) and relational data base management systems (RDBMS). MMS implementations support a variety of communications links including Ethernet, Token Bus, RS-232C, OSI, TCP/IP, MiniMAP, FAIS, etc. and can connect to many more types of systems using networking bridges, routers, and gateways.
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: 1) Interoperability, 2) Independence and 3) Access.
Interoperability is the ability of two or more networked applications to exchange useful supervisory control and process data information between them without the user of the applications having to create the communications environment. While many communication protocols can provide some level of interoperability, many of them are either too specific (to brand/type of application or device, network connectivity, or function performed -- see Independence below) or not specific enough (provide too many choices for how a developer uses the network).
Independence allows interoperability to be achieved independent of:
Data Access is the ability of networked applications to obtain the information required by an application. Although virtually any communications scheme can provide access to data at least in some minimal manner, they lack the other benefits of MMS particularly Independence (see above).
MMS is rigorous enough to minimize the differences between applications performing similar or complimentary functions while still being generic enough for many different kinds of applications and devices. Communications schemes that are not specific enough can result in applications that all perform similar or complimentary functions in different ways. The result is applications that cannot communicate with each other because the developers all made different choices when implementing. While many communications schemes only provide a mechanism for trasmitting a sequence of bytes (a message) across a network, MMS does much more. MMS also provides definition, structure and meaning to the messages that significantly enhances the likelihood of two independently developed applications interoperating. MMS has a rich set of features that facilitate the real-time distribution of data and supervisory control functions across a network in a client/server environment that can be as simple or sophisticated as the application warrants.
The real challenge in trying to develop a business justification for MMS (or any network investment) is in assigning value to the benefits given a specific business goal. In order to do this properly it is important to properly understand the relationship between the application functions, the connectivity functions and the business functions of the network.
In order to assign value to the use of MMS it is important to first understand the role that MMS plays with respect to applications. MMS, as an application layer protocol, provides application services to the business functions, not connectivity services. It is common to view the network simply as a mechanism to transfer messages (connectivity only). That view hides the value of the application functions because they become indistinguishable from the business applications which must then provide the network application functions. However, the costs are still there. Justifying MMS requires that the user recognize the value provided by the network application functions in facilitating interoperability, independence and access to data.
In some cases the benefit of the common communications infrastructure MMS provides is only realized as the system is used, maintained, modified, and expanded over time. Therefore a justification for such a system must look at life cycle costs versus just the purchase price. It is also important not to underestimate the cost associated with developing, maintaining, and expanding the application functions that have to be created if MMS is not used. A key element in assigning value is understanding that the business functions are what provide value to the enterprise. The cost of the custom network application functions directly reduces the amount of effort (i.e. cost) that can be placed on developing, maintaining, and expanding the business functions. With MMS, the communications infrastructure is built once and then re-used by all the business functions.
The key feature of MMS is the Virtual Manufacturing Device (VMD) model. The VMD model specifies how MMS devices , also called servers, behave as viewed from an external MMS client application point of view. MMS allows any application or device to provide both client and server functions simultaneously. In general the VMD model defines:
The remainder of this overview of MMS will provide a summary of the objects defined by the VMD model and the MMS services provided to access and manipulate those objects. While the range of objects and services is broad, a given device or application need only implement whatever subset of these objects and services that are useful in that situation. A more detailed discussion of the MMS VMD model and the various MMS objects and their services will be presented following this overview.
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). MMS provides services such as Status, UnsolicitedStatus, and Identify for obtaining information and status about the VMD. It also provides services like GetNameList and Rename for managing and obtaining information about objects defined in the VMD.
MMS provides a comprehensive and flexible frameworkfor exchanging variable information over a network. The MMS variable access model includes capabilities for named, unnamed (addressed), and named lists of variables. MMS also allows the type description of the variables to be manipulated as a separate MMS object (named type object). MMS variables can be simple (e.g. integer, boolean, floating point, string, etc.) or complex (e.g. arrays and structures). The services available to access and manage MMS variable and type objects are very powerful and include services for:
Service options allow groups of variables to be accessed in a single MMS request, allow large arrays and complex structures to be partially accessed (alternate access), and allow clients to recast variable types and complex structures to suit their needs (access by description).
The VMD execution model defines two objects for controlling the execution of programs within the VMD. A MMS domain is defined as an object that represents a resource within the VMD (e.g. the memory in which a program is stored). A program invocations is defined as a group of domains the execution of which can be controlled and monitored. Some of the features of the services the VMD execution model provides for MMS clients are:
State changes in program invocations can be linked to MMS events.
The MMS event management model defines several named objects consisting of:
The event management model provides a rich set of services for MMS clients:
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 coulduse semaphores to only allow one client at a time to be able to change the setpoint. (e.g. with the MMS Write service). The MMS semaphore model defines two kinds of semaphores. Token semaphores are used to represent a specific resource within the control of the VMD. Pool semaphores consist of one or more named tokens each representing a similar but distinct resource under the control of the VMD. MMS provides semaphore services allow MMS clients to:
A MMS journal is a named object that represents a time based record, or log, of data. Each entry in a journal can contain the state of an event, the value of a variable, or character string data (called annotation) that the VMD, or a MMS client, enters into the journal. Services available allow journals to created, read, deleted, and cleared (in whole or in part).
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.
The primary goal of MMS was to specify a standard communications mechanism for devices and computer applications that would achieve a high level of interoperability. In order to achieve this goal it would be necessary for MMS to define much more than just the format of the messages to be exchanged -- a common message format, or protocol, is only one aspect of achieving interoperability. In addition to protocol, the MMS standard also provides definitions for:
This definition of objects, services, and behavior comprises a comprehensive definition of how devices and applications communicate that MMS calls the Virtual Manufacturing Device (VMD) model. The VMD model only specifies the network visible aspects of communications. The internal detail of how a real device implements the VMD model (i.e. the programming language, operating system, CPU type, input/output (I/O) systems, etc.) are not specified by MMS. By focusing only on the network visible aspects of a device, the VMD model is specific enough to provide a high level of interoperability while still being general enough to allow innovation in application/device implementation and making MMS suitable for application across a range of industries and devices types.
A key aspect of the VMD model is the client/server relationship between networked applications and/or devices. A server is a device or application that contains a VMD and its objects (variables, etc.). A client is a networked application (or device) that asks for data or an action from the server. In a very general sense, a client is a network entity that issues MMS service requests to a server. A server is a network entity that responds to the MMS requests of a client. While MMS defines the services for both clients and servers, the VMD model defines the network visible behavior of servers only.
Many MMS applications and MMS compatible devices provide both MMS client and server functions. The VMD model would only define the behavior of the server functions of those applications. Any MMS application or device that provides MMS server functions must follow the VMD model for all the network visible aspects of the server application or device. MMS clients are only required to conform to rules governing message format or construction and sequencing of messages (the protocol).
There is a distinction between a real device (e.g. a PLC, CNC, or robot) and the real objects contained in it (e.g. variables, programs, etc.) and the virtual device and objects defined by the VMD model. Real devices and objects have peculiarities (a.k.a. product features) associated with them that are unique to each brand of device or application. Virtual devices and objects conform to the VMD model and are independent of brand, language, operating system, etc. Each developer of a MMS server device or MMS server application is responsible for "hiding" the details of their real devices and objects, by providing an executive function. The executive function translates the real devices and objects into the virtual ones defined by the VMD model when communicating with MMS client applications and devices. Because MMS clients always interact with the virtual device and objects defined by the VMD model, the client applications are isolated from the specifics of the real devices and objects. A properly designed MMS client application can communicate with many different brands and types of devices in the same manner because the details of the real devices and objects are hidden from the MMS client by the executive function in each VMD. This virtual approach to describing server behavior does not constrain the development of innovative devices and product features and improvements. The MMS VMD model places constraints only on the network visible aspects of the virtual devices and objects, not the real ones.
The implementor of the executive function (the application or device developer) must decide how to "model" the real objects as virtual objects. The manner in which these objects are modeled is critical to achieving interoperability between clients and servers among many different developers. Inappropriate or incorrect modeling can lead to an implementation that is difficult to use or difficult to interoperate with.
For instance, take the situation of a PLC that contains a ladder program (a real object). The MMS implementor (the designer of the executive function) wishes to allow external client applications to copy the program from the PLC to another computer. For the purposes of this example we shall assume that the MMS VMD model gives the implementor the choice of modeling the ladder program object as a variable or domain object (both virtual objects). The choice of which virtual object to map to the real ladder program object is critical because MMS provides a set of services to manipulate variables that are quite different from the services used to manipulate domains. Variables can be read individually or in a list of typed data. Domains can be copied in whole only. If the ladder program is modeled as a MMS variable it makes the task of performing a simple copying of the program complex because the nature of the ladder program data (typically a large block of contiguous memory) would result in an extremely large variable that would be difficult to access easily. If the ladder program is modeled as a domain, there are specific MMS services provided for uploading and downloading the large blocks of untyped data typical of ladder programs. An incorrect modeling choice can make the real object difficult to access.
In some cases it makes sense to represent the same real object with two different MMS objects. For instance, a large block of variables may also be modeled as a domain. This would provide the MMS client the choice of services to use when accessing the data. The variable services would give access to the individual elements in the block. The domain services would allow the entire block to be read/uploaded or written/downloaded as an element of a program invocation (see the batch controller example of page 16).
In many cases the relationship between the real objects and the virtual objects can be standardized for a particular class of device or application (e.g. a PLC or PCS). Developers and users of these real devices can define more precisely how MMS is applied to a particular class of device or application. The result is a companion standard. In general, companion standards perform the following functions:
A companion standard, after proceeding through all the committees and work needed to become an ISO international standard, becomes a companion of the MMS standard as an additional part. The robot companion standard is ISO 9506 part 3, the NC companion standard will be ISO 9506 part 4, the PLC companion standard will be ISO 9506 part 5, and the PCS companion standard will be ISO 9506 part 6.
The reader should be aware that, for most systems, companion standards are not necessary even when using devices for which companion standards exist. The core MMS services defined in parts 1 and 2 of MMS provides sufficient standardization to achieve interoperability in most cases. Furthermore, aspects of the companion standards such as object naming, usage, and modeling conventions can be used in a core MMS application without having to implement the entire companion standard.
MMS defines a variety of objects that are found in many typical devices and applications requiring real-time communications. A list of these objects is given below. For each object there are corresponding MMS services that let client applications access and manipulate those objects. The model for these objects and the services available are described in more detail later.
Associated with each object are a set of attributes that describe that object. MMS objects have a name attribute and other attributes that vary from object to object. Variables have attributes like, name, value, type, etc. while other objects, program invocations for instance, have attributes like name and current state.
Subordinate objects exist only within the scope of another object. For instance, all other objects are subordinate to, or contained within, the VMD itself. Some objects, such as the operator station object for example, may be subordinate only to the VMD. Some objects by be contained within other objects such as variables contained within a domain. This attribute of an object is called its scope. The object's scope also reflects the lifetime of an object. An object's scope may be defined to be:
The name of a MMS object must also reflect the scope of the object. For instance, the object name for a domain-specific variable must not only specify the name of the variable within that domain but also the name of the domain. Names of a given scope must be unique. For instance, the name of a variable specific to a given domain must be unique for all domain specific variables in that domain. Some objects, such as variables, are capable of being defined with any of the scopes described above. Others, like semaphores for example, cannot be defined to be AA-specific. Still others, like operator stations for example, are only defined as VMD-specific. When an object like a domain is deleted, all the objects subordinate to that domain must also be deleted.
The VMD itself is also an object and has attributes associated with it. Some of the network visible attributes for a VMD are:
The VMD model has a flexible execution model that provides a definition of how the execution of programs by the MMS server can be controlled. Central to this execution model are the definitions of the domain and program invocation objects.
The MMS domain is a named MMS object that is a representation of some resource within the real device. This resource can be anything that is appropriately represented as a contiguous block of untyped data (referred to as load data). In many typical applications domains are used to represent areas of memory in a device. For instance, a PLC's ladder program memory is typically represented as a domain. Some applications allow blocks of variable data to be represented as both domains and variables. MMS provides no definition for, and imposes no constraints on, the content of a domain. To do so would be equivalent to defining a "real" object (i.e. the ladder program). The content of the domain is left to the implementor of the VMD. In addition to the name, some of the attributes associated with MMS domains are:
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:
It is through the manipulation of program invocations that a MMS client controls the execution of programs in a VMD. Program invocations can be started, stopped, reset, etc. by MMS clients. A program invocation is an execution thread which consists of a collection of one or more domains. Simple devices with simple execution structures may only support a single program invocation containing only one domain. More sophisticated devices and applications may support multiple program invocations containing several domains.
As an example, consider how the MMS execution model could be applied to
a personal computer (PC). When the PC powers up, it downloads a domain
called the operating system into memory. When you type the name of the
program you want to run and hit the
The MMS services for program invocations allow clients to control the execution of VMD programs and to manage program invocations as follows:
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:
A MMS variable address can take on one of several forms. Which specific form that is used by a specific VMD, and the specific conventions used by that address form, is determined by the implementor of the VMD based upon what is most appropriate for that device. The possible forms for a MMS variable address are:
In general, it is recommended that applications utilize named variable objects instead of the addresses of unnamed variable objects wherever feasible. Address formats vary widely from device to device. Furthermore, in some computing environments, the addresses of variables can change from one run-time to the next. Names provide a more intuitive, descriptive and device independent access method than addresses.
MMS also defines a named variable list object that provides an access mechanism for grouping both named and unnamed variable objects into a single object for easier access. A named variable list is accessed by a MMS client by specifying the name (which also specifies its scope) of the named variable list. When the VMD receives the Read service request from a client, it reads all the individual objects in the list and returns their value within the individual elements of the named variable list. Because the named variable list object contains independent subordinate objects, a positive confirmation to a Read request for a named variable list may indicate only partial success. The success/failure status of each individual element in the confirmation must be examined by the client to ensure that all of the underlying variable objects were accessed without error. In addition to its name and the list of underlying named and unnamed variable objects, named variable list objects also have a MMS deletable attribute that indicates whether or not the named variable list can be deleted via a DeleteNamedVariableList service request.
The type of a variable indicates its format and the possible range of values that the variable can take. Examples of type descriptions include 16-bit signed integer, double precision floating point, 16 character string, etc. MMS allows the type of a variable to be either 1) described or 2) defined as a separate named object called a named type. A described type is not an object. It is a binary description of the type in a MMS service request (i.e. Read, Write, or InformationReport) that uses the Access by Description service option. The named type object allows the types of variables to be defined and managed separately. This can be particularly useful for systems that also use the DefineNamedVariable service to define names and types for unnamed variable objects. Other attributes of the named type object include:
The specification for a MMS type description is very flexible and can describe virtually any data format in use today. As mentioned earlier, the type description specifies the format of a variable and the range of values that that variable can represent. MMS defines three basic formats for types: 1) simple, 2) array and 3) structured:
The Read, Write and InformationReport services provide several features for accessing Variables. The use of these service features, described below, by MMS clients can provide enhanced performance and very flexible access to MMS Variables.
Access by Description is supported for unnamed variable objects only. It allows the MMS client to describe the variable by specifying both an address and a type description. These variables are called described variables. The described type may be different from the type inherently defined for the unnamed variable object. This can be useful for accessing data in devices where the device's memory organization is simplistic. For example, many PLCs represent their data memory as a large block of 16-bit registers (essentially signed integers). Some applications may store ASCII string data in these registers. By using a described variable a MMS client can have the data stored in these registers returned to it as a string instead of as a block of signed integers.
List of Variables. This feature allows a list of named variable, unnamed variable, and named variable list objects to be accessed in a single MMS Read, Write, or InformationReport service. Care must be taken by the client to ensure that the resultant MMS service request message does not exceed the maximum message size (or maximum segment size) supported by the VMD. This option also requires that a client examine the entire response for success/failure for each individual element in the list of Variables.
Access Specification in Result is an option for the Read service that allows a MMS client to request that the variable's access specification be returned in the Read response. The access specification would consist of the same information that would be returned by a GetVariableAccessAttributes service request.
Alternate Access allows a MMS client to 1) partially access only specified elements contained in a larger arrayed and/or structured variable, and 2) rearrange the ordering of the elements contained in structured variables.
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.
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. The MMS event management model defines two classes of event conditions:
In addition to the name of the event condition (an object name that also reflects its scope) and its class (NETWORK TRIGGERED or MONITORED), MMS defines the following attributes for both network triggered and monitored event conditions:
Additionally, MMS also defines the following attributes for Monitored event conditions only:
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:
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. In addition to its name, the attributes of an event enrollment are:
MMS provides services for notifying clients of event condition transitions and acknowledging those event notifications as follows:
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.
Because semaphores either represent a real resource or are used for the purpose of coordinating activities between two or more MMS clients, the scope of a semaphore cannot be AA-Specific. If an object's scope is AA-Specific there can be only one client. Also, AA-Specific objects only exist as long as the application association exists while real resources must exist outside the scope of any given application association. In addition to its name the token semaphore has the following attributes:
A pool semaphore is similar to a token semaphore except that the individual tokens are identifiable and have a name associated with them. These named tokens can optionally be specified by the MMS client when issuing TakeControl requests. The pool semaphore itself is a MMS object. The named tokens contained in the pool semaphore are not MMS objects. They are representations of a real resource in much the same way an unnamed variable object is. The name of the pool semaphore is separate from the names of the named tokens. Pool semaphores can only be used to represent some real resource within the VMD. Therefore, pool semaphores cannot be created or deleted using MMS service requests and cannot be AA-Specific in scope. In addition to the name of a pool semaphore the following attributes also are defined by MMS:
When a MMS client issues a TakeControl request for a given semaphore the VMD creates an entry in an internal queue that is maintained for each semaphore. Each entry in this queue is called a semaphore entry. The attributes of a semaphore entry are visible to MMS clients and provide information about the internal semaphore processing queue in the VMD. The semaphore entry is not a MMS object. It only exists from the receipt of the TakeControl indication by the VMD until the token control of the semaphore is relinquished or if the VMD responds negatively to the TakeControl request. The semaphore entry reflects the state of the relationship between the client and the semaphore. Several of the attributes of the semaphore entry are specified by the client in the TakeControl request. These attributes are:
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:
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. The services used by MMS clients to perform operator communications are:
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:
The services available for MMS journals are as follows:
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:
MMS provides services for managing the context of communications between two MMS nodes on a network. These services are used to establish and terminate application associations and for handling protocol errors between two MMS nodes. The node that initiates the association with another node is referred to as the calling node. The responding node is referred to as the called node.
In a MMS environment, two MMS applications establish an application association between themselves using the MMS Initiate service. This process of establishing an application association consists of an exchange of some parameters and a negotiation of other parameters. The exchanged parameters include information about restrictions that pertain to each node that are determined solely by that node (e.g. which MMS services are supported). The negotiated parameters are items where the called node either accepts the parameter proposed by the calling node or adjusts it downward as it requires (e.g. the maximum message size). The calling application issues an Initiate service request that contains information about the calling node's restrictions and a proposed set of the negotiated parameters. The called node examines the negotiated parameters and adjusts them as necessary to meets its requirements and then returns the results of this negotiation and the information about it's restrictions in the Initiate response. Once the calling node receives the Initiate confirmation the application association is established and other MMS service requests can then be exchanged between the applications.
Once an application association is established either node can assume the role of client or server independent of which node was the calling or called node. For any given set of MMS services one application assumes the client role while the other assumes the role of server or VMD. Whether or not a particular MMS application is a client, server (VMD), or both is determined solely by the developer of the application.
Although many people may refer to network connections and application associations interchangeably there is a distinct difference. A connection is an attribute of the underlying network layers that represents a virtual circuit between two nodes. For instance, telephone networks require that two parties establish a connection between themselves (by dialing and answering) before they can communicate at all. An application association is an agreement between two networked applications governing their communications. It is analogous to the two parties agreeing to use a particular language and to not speak about religion or politics over the telephone. Application associations exist independent of any underlying network connections (or lack thereof).
In a connection oriented environment the MMS Initiate service is used to signal to the lower layers that a connection must be established. The Initiate service request is carried by the network through the layers as each layer goes through its connection establishment procedure until the Initiate indication is received by the called node. The connection does not exist until after all the layers in both nodes have completed their connection establishment procedures and the calling node has received the Initiate confirmation. Because of this, the association and the connection occur simultaneously in a connection oriented environment.
In a connectionless environment, it is not strictly necessary to send the Initiate request before two nodes can actually communicate. In an environment where the Initiate service request is not used before other service requests are issued by a MMS client to a VMD, each application must have all the knowledge regarding the other application's exchanged and negotiated parameters via some local means (e.g. a configuration file). This foreknowledge of the other MMS application's restrictions is the application association from a MMS perspective. Whether an Initiate service request is used or not, application associations between two MMS applications must exist before communications can take place. In some connectionless environment such as MiniMAP, MMS nodes still use the Initiate service to establish the application association before communicating.
Ralph Mackiewicz SISCO, Inc. 6605 19-1/2 Mile Road Stelring Heights, MI 48314 USA T: +810-254-0020 F: +810-254-0053 E: siscoinfo@delphi.com (company) 75776.1400@compuserve.com (personal)
$Id: mms.html 1.1 1995/07/12 23:39:03 thb Exp thb $