The MMS Client/Server model

MMS models the behavior of two devices in the form of a Client/Server model (see figure 2). The client can for example be an operating and monitoring system, a control center or another intelligent device. The server represents one or several real devices or whole systems. MMS uses an object-oriented modeling method with object classes (Named Variable, Domain, Program Invocation, Event Condition etc.), instances from the object classes and methods (services like read, write, store, start, stop etc.).

Figure 2: MMS Client/Server Model

The complexity of the standard indicates not at all that a MMS implementation must be complex or really complicated. If only a simple subset is used, then the implementation is also simple. Meanwhile MMS implementations are available in the third generation. They allow the use of MMS both in microprocessor based applications and in simple field controllers.

The MMS server contains the objects which the MMS client can access. The VMD object (Virtual Manufacturing Device) represents the outermost "container" in which all other objects are located.

Real devices can play both roles (client and server) simultaneously. A server in a control center for its part can be client with respect to a subordinate station. MMS basically describes the behavior of the server. The server contains the MMS objects and it also executes services. MMS can be regarded as "server centric". In principle, in a system more devices are installed which function as server (for example controllers and field devices) than such devices which perform the client task (e. g. PC and workstation). Therefore, at the definition of a service special care has always been taken that the server must carry little load.

The calls which the client sends to the server are described in the part ISO/IEC 9506-1 (services). These calls are processed and answered by the server. The services can also be referred to as remote calls, commands or methods. Using these services, the client can access the objects in the server. It can for example browse through the server, i.e. making visible all available objects and their definitions (configurations). The client can define, delete, change, or access objects via reading and writing. Several measurements for example can be graped and provided with an application-specific name during definition.

A MMS server models real data (e. g. temperature measurement, counted measurand or other data of a device). These real data and their implementation are concealed or hidden by the server. MMS doesn't define any implementation details of the servers. It is only defined how the objects behave and represent themselves to the outside (from the point of view of the wire) and how a client can access them.

3.1 The Virtual Manufacturing Device (VMD)

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:

• objects (e.g. variables) that are contained in the server,
• the services that a client can use to access and manipulate these objects (e.g. read or write a variable), and
• the behavior of the server upon receipt of these service requests from clients.

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.

According to figure 3, the real data and devices are represented - from a client point of view - by the VMD (Virtual Manufacturing Device). So, the server represents a quasi standard driver which maps the real world to a virtual one. The following definition helps to clarify the modeling in the form of a virtual device:

If it's there and you can see it If it's there and you can't see it If it's not there and you can see it If it's not there and you can't see it	It's REAL It's TRANSPARENT It's VIRTUAL It's GONE
Roy Wills

Figure 3: Hiding real devices in the Virtual Manufacturing Device (VMD)

The VMD can represent, for example, a variable "Measurement_3" whose value does not permanently exist in reality; only when the variable is being read, a measurand transducer will get started to determinate the value. All objects in a server can already be contained in a device before the delivery of a device. The objects are predefined in this case.

Independent of the implementation of a VMD, data and the access to them are always treated in the same way. This is completely independent of the operating system, the programming and memory management. Like printer drivers for a standard operating system hide the various real printers, so a VMD also hides real devices. The server can be understood as a communication driver which hides the specifics of real devices. From the point of view of the client, only the server with its objects and its behavior is visible. The real device isn't visible directly.

MMS merely describes the server side of the communication (objects and services) and the messages which are exchanged between client and server.

The VMD describes a virtual device (Virtual Manufacturing Device, VMD) completely. This virtual device represents the behavior of a real device as far as it is visible "over the wire". It contains for example an identification of manufacturer, device type and version. The virtual device contains objects like variables, lists, programs and data areas, semaphores, events, journals etc.

The client can read the attributes of the VMD (see figure 4), i.e. it can browse through a device. If the client doesn't have any information about the device, it can view all the objects of the VMD and their attributes by means of the different Get services. With that the client can perform a first plausibility check on a just installed device by means of a Get(Object-Attribute)-Service. It learns whether the installed device is the ordered device with the right model number (Model Name) and the expected issue number (Revision). All other attributes can also be checked (for example variable names and types).

Figure 4: VMD Attributes

The attributes of all objects represent a self-description of the device. Since they are stored in the device itself, a VMD always has the currently valid and thus consistent configuration information of the respective device. This information can be requested online directly from the device. In this way, the client receives always up to date information.

MMS defines about 80 functions which can be grouped as follows:

• enquiry functions about the "contents" of the virtual device: "Which objects are available?", "How are they defined?", ... ,
• functions for reading, reporting and writing of arbitrarily structured variable values,
• functions for the transmission of data and programs, for the control of programs and many other functions.

The individual groups of the MMS services and objects are shown in figure 5. MMS describes such aspects of the real device that shall be open i.e. standardized. An open device must behave as described by the virtual device. How this behavior is achieved is not visible and also not relevant to the user that accesses the device externally. MMS doesn't define any local, specific interfaces in the real systems. The interfaces are independent of the functions which shall be used remotely. Interfaces in connection with MMS are always understood in the sense that MMS quasi represents an interface between the devices and not within the devices. This interface could be described as an external interface. Of course, interfaces are also needed for implementations of MMS functions in the individual real devices. These shall not and cannot be defined by a single standard. They are basically dependent on the real systems - and these vary to a great extent.

Figure 5: MMS Objects and Services

3.2 Where VMDs can be located

VMDs are virtual descriptions of real data and devices (e. g. protection devices, measurand transducers and any other automation device or system). Regarding the implementation of a VMD, there are three very different possibilities where a VMD can be located (see figure 6):

• In the end device: One or several VMD are in the real device which is represented by the VMD. The implementations of the VMD have direct access to the data in the device. The modeling can be carried out in such a way that each application field in the device is assigned to its own VMD. The individual VMDs are independent from each other.
• In the gateway or proxy: One or several VMD are implemented in a separate computer (a so-called gateway or proxy). In this case, all MMS objects that describe the access to real data in the devices are at a central location. While being accessed, the data of a VMD can be in the memory of the gateway (independently updated in the background) - or they must be retrieved from the end-device only after the request. The modeling can be carried out in such a way that for each device or application a VMD of its own will be implemented. The VMD are independent from each other.
• In a file: One or several VMD are implemented in a data base on a computer, on a FTP server or on a CD ROM (the possibilities above are still valid here). Thus, all VMD and all included objects with all their configuration information can be entered directly into engineering systems. Such a CD ROM, which represents the device description, also could be used for example to provide a monitoring system with the configuration information: names, data types, object attributes etc. Before devices are delivered, the engineering tools can already process the accompanying device configuration information (Electronic Data Sheet)! The configuration information can also be read later online from the respective VMD via corresponding MMS requests.

Figure 6: Location of VMDs

The VMD is independent of the location. This also allows for example - besides the support during configuration - that several VMD can be installed for testing purposes on another computer than the final system (see figure 7). Thus, the VMD of several large robots can be tested in the laboratory or office. The VMD will be installed on one or several computers (the computers emulate the real robots). Using a suitable communication (for example intranet or also a simple RS 232 connection - available on every PC), the original client (a control system which controls and supervises the robots) can now access and test the VMD in the laboratory. This way, whole systems can be tested beforehand regarding the interaction of individual devices (for example monitoring and control system).

Figure 7: VMD testing using PC in an office environment

If the internet is used instead of the intranet, global access is possible to any VMD which is connected to the internet. The author himself tested the access from Germany to a VMD which is implemented on a PLC in the USA. That is to say, through standards like MMS and open transmission systems it has become possible to set up global communications networks for the real-time process data exchange.

Figure 8 depicts the possibility emulate a server application using a the binary code of the server and run it on a PC in a test lab. This server behaves as it would be the real device. The client application software can now be configured and tested against that test server - without installing the real device.

Figure 8: Testing in a test lab

The previous statements about the VMD are valid in full extent also for UCA which has adopted and refined the VMD model.

3.3 Is MMS an Interface?

The increasing distribution of automation applications and the exploding amount of information require more and more and increasingly more complex interfaces for operation and monitoring. Complex interfaces turn into complicated interfaces very fast. Interfaces cut components in two pieces (see figure 9); through this, interactions between the emerged sub-components - which were hidden in one component before - become visible. An interface discloses which functions are carried out in the individual sub-components and how they act in combination.

Figure 9: Interface between systems

In order to be able to communicate semantic definitions are necessary beyond the limits of specific interfaces. Transmitter and receiver must likewise be able to understand these definitions. Figure 9 shows the necessity of uniform interfaces. The request "Read T142" must be formulated "understandably", transmitted correctly and understood unambiguously.

Interfaces occur in two forms:

• internal program-program interfaces or APIs and
• external interfaces over a network (WAN, LAN, fieldbus, ...).

Both interfaces affect each other. MMS defines an external interface. The necessity of complex interfaces (complex because of the necessary functionality, not because of an end in itself) is generally known and accepted. To keep the number of complex interfaces as small as possible, they are defined in standards or industry standards - mostly as open interfaces. Open interfaces are in the meantime integral component of every modern automation. In Mid 1997 it was explained in [22] that the trend in automation engineering obviously leads away from the proprietary solutions to open, standardized interfaces - i.e. to open systems.

APIs and (remote) Protocols define different aspects of the system. An API function "Is A=B" is the same independent of the protocol between an engineeriunfg tool and a remote device. There may even be no protocol at all! Different cases are depicted to show the independency:

The reason why open interfaces are complicated is not because they were standardized. Proprietary interfaces tend more towards being complicated or even very complicated. The major reasons for the latter observation are found in the permanent "improvement" of the interfaces which expresses itself in the quick changes of version and in the permanent development of new - apparently better - interfaces. Automation systems of one manufacturer often offer - for identical functions - a variety of complicated interfaces which are incompatible to each other.

At first, interfaces can be divided up into two classes (see figure 10): internal interfaces (for example in a computer) and external interfaces (over a communication network). The following consideration is strongly simplified because e. g. in reality both internally and externally several interfaces can lie one above the other. However, it nevertheless shows the differences in principle which must be paid attention to. MMS defines an external interface. Many understand MMS in such a way that it offers - or at least also offers - an internal interface. This notion results in completely false ideas. Therefore, the following consideration is very helpful.

The left hand side of the figure shows the case with an uniform internal interface and varying external interfaces. This uniform internal interface allows many applications to access the same functions with the same parameters and perhaps the same programming language - independent of the external interface. Uniform internal interfaces basically allow the portability of the application programs over different external interfaces.

The right hand side of the figure shows the case with the external interface being uniform. The internal interfaces are various (since the programming languages or the operating systems for example are various). The uniform external interface is independent of the internal interface. The consequence of this is for example that devices whose local interfaces differ and are implemented in divers environments can communicate together. Differences can result, for example, from an interface being integrated into the application in a certain device, but being available explicitly in another device. The essential feature of this uniform external interface is the interoperability of different devices. The ISO/OSI reference model is aimed at exactly this feature.

Figure 10: Internal and external interfaces

The (internal) MMS interface, for example in a client (perhaps: $READ (Par. 1, Par. 2, ... Par. N)), depends on manufacturer, operating system and programming language. MMS implementations are for example available for UNIX or Windows NT. On the one hand, this is a disadvantage because applications which want to access a MMS server would have to support - depending on environment - various real program interfaces. On the other hand, the MMS protocol is completely independent of the - fast changing - operating system platforms. Standardized external interfaces like MMS offer a high degree on stability, because in the first place the communication can hardly be changed arbitrarily by a manufacturer and in the second place several design cycles of devices can survive.

Precisely the stability of the communication, as it is defined in MMS, also offers a stable basis for the development of internal interfaces on the various platforms such as under Windows 95, NT or in UNIX environments.

Openness describes in the ISO/OSI world the interface on the "wire". The protocol of this external interface executes according to defined standardized rules. For an interaction of two components these rules have to be taken into account on the two sides; otherwise the two will not understand each other.