# ISO generic PLC query protocol

K

#### Ken Irving

On Fri, Feb 04, 2000 at 11:03:26AM -0500, Ralph Mackiewicz wrote: (in thread "Re: COMM: Is Siemens PPI a closed protocol")
>...
> Neglected in this argument is the fact that neither CAN nor TCP/IP are sufficiently defined by themselves to allow the manufacturer of any piece of industrial control equipment to have any hope of interoperating with anyone else. For instance, how does the commoditized version of TCP/IP using a standard TCP socket provide a
service for reading a variable? ... <

TCP/IP is good for moving packets, but an application protocol is needed on top of it to do things. What about defining a protocol to do what
you ask? Perhaps one of the many existing protocols can do this, but I'm not aware of a suitable one.

I would like to use a "generic" PLC query protocol to interact with a few different PLCs (and other systems), and I'm thinking of defining one for the purpose. XML (extensible markup language) can provide a verbose mechanism to do this in a clear and obvious way, I think, by using terms similar to what you used above, i.e., by explicitly stating the query in the message.

In a prototype server, access details for each anticipated PLC are stored in configuration files, so that the query only needs to identify the site; the type of PLC is specified in the config files. The PLC type could alternatively specified in the query protocol, as well as the
access parameters (communications channel, logon id, password, etc.)

Here's an example query:

<PLCS site="owner1/site3">
<GET type="register">4002</GET>
<GET>type="symbolic">fan13_motor_amps</GET>
<GET>a_variable</GET>
</PLCS>

In the latter GET query no type attribute is specified, so the server would provide a default one, perhaps based on the nature of the variable
name provided.

I don't know how far such a thing can be taken, but I think I can define a workable protocol for the few target controller types I'm familiar with.
One problem is that different systems may have very different conceptual models, and it is likely difficult to express the details of one in the syntax of another. However, I think it should be possible to express at least some useful queries in a generic way, i.e., to provide a generic PLC interface.

This may seem like a case of YAP (yet another protocol), but I really haven't found one that I can use as is. BACnet may be close to what I'm after, but I haven't ponied up my $119 to read it yet. ;-) -- Ken Irving Trident Software [email protected] R #### Ralph Mackiewicz YAP. Exactly. This is why we have so many "open" protocols in the industrial automation field. Everyone has a hot button that needs to be pressed. If you don't find a match for what you want, or if an existing solution is supported by a vendor that you don't like, or if the standard was created by the despised consensus method, or if a tradeoff is required, then the answer is always to develop another one. After all, it only takes a day or so to develop a DDE server to support any given protocol! ;-) Regards, Ralph Mackiewicz SISCO, Inc. K #### Ken Irving One of the "problems" is that it is easy to define such protocols for a specific task, probably (much) easier (and more fun) than researching the existing ones and then applying one of them to the task. Setting up even nominal barriers to such research works against the goal that I think you imply, i.e., not inventing new protocols. Ironically, it would seem to me that commercial interests almost guarantee the reinvention of wheels, since each vendor protects their wheels (protocols) as valuable intellectual property, so that they can compete with others doing the exact same thing. If those protocols are instead made public, then people can just follow them and get on with their job. Examples of public protocols include all of the web, email, time, and other services that make up the burgeoning Internet. I certainly do not mean that commercial interests are bad, but I do feel that communications protocols might better be considered as public infrastructure than as private property. Perhaps an analogy could be made with independent railways, each with its own track specs (protocols), making engines and cars (controllers, interface products) completely incompatible with other railways. Yes, I do realize that industry groups (ASHRAE, ISA, etc.) do have real costs of development and of distrubution of their protocols, and no, I do not have a solution to how these costs are to be met. If there is a (suitable ;-) protocol defined and available for what I want to do, I would (sincerely!) like to know about it, and I will (grudgingly) pay the fee. I have studied some of the protocols, including some (e.g., Modbus) that are freely available on the web, and have tried to read everything I can find on some others (e.g., BACnet, including perusing the API of a commercial product to try to understand the spec) which are not. I am not averse to spending the nominal fee, but (as someone else said in the original thread),$100 here and $2000 there, and pretty soon you're talking some real money, at least for us little guys. ;-) Informationally, it should be sufficient to compose a query for any given PLC (or other target) by specifying the site, the make, model, and version of the target system, and the data (e.g., point names, register values, file content, etc.) that is desired. A server would dispatch the query to a handler for that target, which might be a commercial DDE server or a custom server polling a system. That's all I'm trying to do, to effect a generic PLC server, albeit limited to some small set of target systems. I think that BACnet, designed by consensus and committee for perhaps for one corner of the automation industry, might be a viable solution for the problem. Its authors were aiming at a vendor independent solution, and did try to accomodate "generic" queries, i.e., by basing the protocol on a conceptual model of a control system. Whether that model is a good enough fit to other systems (e.g., industrial PLCs), I don't know. Whether there is too much baggage in the protocol for my simple needs I also do not know, yet. -- Ken Irving Trident Software [email protected] H #### Hullsiek, William On Wed, Feb 09, 2000 at 08:52:33AM -0500, Ralph Mackiewicz wrote: > > TCP/IP is good for moving packets, but an application protocol is > > needed on top of it to do things. What about defining a protocol to > > do what you ask? Perhaps one of the many existing protocols can do > > this, but I'm not aware of a suitable one. > > > > I would like to use a "generic" PLC query protocol to interact with a > > few different PLCs (and other systems), and I'm thinking of defining > > one for the purpose. XML (extensible markup language) can provide a > > verbose mechanism to do this in a clear and obvious way, I think, by > > using terms similar to what you used above, i.e., by explicitly > > stating the query in the message. > > > > ...snip...snip... > Just remember, MMS was a simple redesign of MMFS, that was supposed to take only a few weeks of programming. The IP protocol suite is readily available, because alot of the work was done for free by graduate students in Universities. Many companies took the free source code, ported it to their embedded OS, and turned it into a product for a reasonable low-cost. Some of the more "modern" protocols do not work well in embedded devices, that have memory constraints, and other limitations. We first should be working on a common "Extensible" object model to support the application. Then look at required services and properties. Then we can worry about protocol design. XML notatation in a RPC type of protocol might be a valid "open" approach. Depending on what type of objects we are manipulating. William F. Hullsiek Software Engineer C #### Curt Wuollet Ken Irving wrote: > One of the "problems" is that it is easy to define such protocols for > a specific task, probably (much) easier (and more fun) than researching > the existing ones and then applying one of them to the task. Setting up > even nominal barriers to such research works against the goal that I > think you imply, i.e., not inventing new protocols. > > Ironically, it would seem to me that commercial interests almost > guarantee the reinvention of wheels, since each vendor protects their > wheels (protocols) as valuable intellectual property, so that they can > compete with others doing the exact same thing. If those protocols are > instead made public, then people can just follow them and get on with > their job. Examples of public protocols include all of the web, email, > time, and other services that make up the burgeoning Internet. All of those protocols were developed by real people who had to eat, etc. Yet, somehow, each contributing a little made for one of the best examples of community cooperation for advancement of the state of art. It is excessive competitive zeal that is holding back advancement in this market. That's why automation moves at a glacial pace compared to the new cybereconomy. The good news is that it's a case of "Lead, follow, or get out of the way". and advancement in the general computing and Open Source world will simply work around the proprietary roadblock. A couple years from now, most of the closed protos will run on top of TCP/IP and the rest will be termed "legacy" but will be around for at least twenty years and used where you really need something special. > I certainly do not mean that commercial interests are bad, but I do > feel that communications protocols might better be considered as public > infrastructure than as private property. Perhaps an analogy could be made > with independent railways, each with its own track specs (protocols), > making engines and cars (controllers, interface products) completely > incompatible with other railways. > > Yes, I do realize that industry groups (ASHRAE, ISA, etc.) do have real > costs of development and of distrubution of their protocols, and no, > I do not have a solution to how these costs are to be met. If there is > a (suitable ;-) protocol defined and available for what I want to do, > I would (sincerely!) like to know about it, and I will (grudgingly) > pay the fee. Linux cost millions of dollars worth of time to create. It simply could not have been done by a few. If you could get hundreds of companies contributing to a standard instead of a closed clique of half a dozen these costs could be absorbed without pain and the standard could be free. All it takes is a community effort. When interoperability becomes a selling point this has a chance of happening. > I have studied some of the protocols, including some (e.g., Modbus) > that are freely available on the web, and have tried to read everything > I can find on some others (e.g., BACnet, including perusing the API of > a commercial product to try to understand the spec) which are not. I > am not averse to spending the nominal fee, but (as someone else said in > the original thread),$100 here and \$2000 there, and pretty soon you're
> talking some real money, at least for us little guys. ;-)

It's even worse than that. Some vendors won't release any information and may sue if you reverse engineer it. Others will let you see the info if you sign an agreement that you won't do exactly what you are trying to do.

> Informationally, it should be sufficient to compose a query for any given
> PLC (or other target) by specifying the site, the make, model, and version
> of the target system, and the data (e.g., point names, register values,
> file content, etc.) that is desired. A server would dispatch the query
> to a handler for that target, which might be a commercial DDE server or
> a custom server polling a system. That's all I'm trying to do, to effect
> a generic PLC server, albeit limited to some small set of target systems.

Most of these protocols will have to be supported by the Linux PLC project and that information will be public so our goals converge,

K

#### Ken Irving

On Thu, Feb 10, 2000 at 09:34:27AM -0600, Hullsiek, William wrote:

>Just remember, MMS was a simple redesign of MMFS, that was supposed to take
>only a few weeks of programming.

MMS (Manufacturing Message Specification) appears to be the sort of system I'm looking for, so I'll study it. It does look quite large and complicated, but nobody said it would be easy. ;-)

...
> We first should be working on a common "Extensible" object model to support
> the application. Then look at required services and properties.
> Then we can worry about protocol design.

Yes, the protocol is a vehicle for the model, and different protocols could be used to transport a given model. BACnet defines a number of devices,
device attributes, and services, it's designed to be extensible, and it exists, so it may be a good choice. MMS has its abstract model, and I'll
try to grok it as well.

--
Ken Irving
Trident Software
[email protected]

L

#### Lynn Linse

> MMS (Manufacturing Message Specification) appears to be the sort of system I'm looking for, so I'll study it. It does look quite large and complicated, but nobody said it would be easy. ;-)
<

Is the spec readily available on the web?

By the way, what ever happended to all the old MAP/TOP documents? Were they archived somewhere? Just flushed? Opened up as public info?

regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
lyn[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132

R

#### Ralph Mackiewicz

> All of those protocols were developed by real people who had to eat, etc. Yet, somehow, each contributing a little made for one of the best examples of community cooperation for advancement
of the state of art. It is excessive competitive zeal that is holding back advancement in this market. That's why automation moves at a glacial pace compared to the new cybereconomy.<

Automation companies are guilty of "excessive competitive zeal" while the dot com companies of the new "cybereconomy" aren't?!?!?!? Did you
leave off the ;-) from the end of this statement?

> A couple years from now, most of the closed protos will run on top of TCP/IP and the rest will be termed "legacy" but will be around for at least twenty years and used where you really need something special. <

The vast majority of these closed protocols are already available running on top of TCP/IP.

> Linux cost millions of dollars worth of time to create. It simply could not have been done by a few.<

It could have been done with a few millionaires who were not interested in turning themselves into billionaires. ;-)

> If you could get hundreds of companies contributing to a standard instead of a closed clique of half a dozen these costs could be absorbed without pain and the standard could be free. All it takes is a community effort. <

Many of the existing standards for which you have to pay the exhorbitant amount of a few hundred dollars were in fact developed exactly in this manner. The cliques developing them weren't closed. They were limited only by those willing to participate. Standards like Profibus, Fieldbus, MMS, UCA, CEBus, BACnet, and many many more were open to anyone willing to contribute the significant time and effort it takes to develop them.

> When interoperability becomes a selling point this has a chance of happening.<

Why is interoperability not a selling point?

Regards,
Ralph Mackiewicz
SISCO, Inc.

The opinions given above should be attributed to me and not my company because my company did not write them...I did.

K

#### Ken Irving

On Fri, Feb 11, 2000 at 08:55:52AM -0800, Lynn Linse wrote:

> Is the spec readily available on the web?

It appears to be, or at least perhaps a detailed API for it. I found it in a web (google) search (for "MMS MMFS") at http://icawww.epfl.ch/MMS/,
but with a note that seemed to indicate that this site is no longer being supported. I do not know what the current status is.

> By the way, what ever happended to all the old MAP/TOP documents? Were they
> archived somewhere? Just flushed? Opened up as public info?

From what I read in an overview by Ralph Mackiewicz, at

http://www.control.auc.dk/~henrik/undervisning/netpro/litt/mms_intr.txt

it appears that MMS grew out of MAP, but I'll leave any other commentary to the experts. ;-)

Ken

--
Ken Irving
Trident Software
[email protected]

H

#### Hullsiek, William

Requirements:

Command, control and monitoring communications technology must be able to meet the following overall requirements:

· The real-time communications infrastructure must provide normal monitoring and control functions like read data, write operator commands,
etc.

· The real-time communications infrastructure must (potentially) be able to disseminate real-time data from any individual field device
interface to all users throughout the enterprise.

· The real-time communications infrastructure must (potentially) be able to get operator commands from many operator workstations scattered
throughout the enterprise to any individual field device interface.

· The real-time communications infrastructure must support a complete set of communications services to command and control applications. This includes functions like message prioritization, uni-cast, multi-cast and broadcast message addressing. The communications infrastructure must provide support and coordination for short and frequent messages (i.e., the real time data). It also must support infrequent large messages (i.e., file transfers and other transactions associated with remote configuration of field device interfaces).

· Performance is a key issue for command and control applications. The real-time communications infrastructure must provide fast enough network speeds, fast enough network routing and switching equipment, and fast enough
processors to meet a given enterprise's requirements.

· The real-time communications infrastructure must support remote management of field device interface equipment. This includes the ability
to change a remote device's real-time monitoring configuration and network communications configuration. It must also be able to query the remote device for its current configuration information, and start and stop control programs and input/output point scans.

· The real-time communications infrastructure must provide security functions to restrict various monitoring and control services to the
appropriate users

· The real-time communications infrastructure must support legacy systems, that is, existing control system devices and their communications
requirements. Quite often this legacy equipment has limited memory and limited computer processing power. Often legacy systems are limited to their existing, proprietary communications protocols, and cannot be upgraded
to new open-system protocols

------
Design:
-------

Protocols for time-critical communications need the following attributes:
· routable
· support for message prioritization
· exception handling
· multi-cast
· event driven
· time granularity in milli-seconds
· handle message sizes in the range of 50 bytes to 10 Kbytes

---------
Solution:
---------

Section 5 of IEC 1131 addresses communications issues for an industry standard real-time controller. This section specifies MMS as the standard communication protocol. It can over OSI or IP networks. Devices complying with IEC 1131 are interoperate with other IEC 1131 devices and non-IEC devices using MMS [ANTS 1995].

The MMS Forum, has tested MMS in a trim-7 architecture. It was found to operate in a 4-5 milli-second response time over a standard Ethernet compared to a 3-4 milli-second response time for a 3 layer architecture in a fieldbus network.

MMS provides the following services:
· create, delete, read and write the following objects:
· data variables
· Alarms and events
· Journal (time history) data sets
· query the configuration of the remote device
· file manipulation and management
· initialize, start, stop, pause, and resume control strategies
· security

MMS is a general purpose protocol that can be used for a wide range of applications. In order to achieve major gains in productivity, the
MMS-Forum has developed standardized object models and service models for interoperation.

MMS is based on the concept of structured variables as opposed to proprietary protocol which are based on points or tags. (Or worse yet a ladder-logic model). It supports data structures and array in addition to simple variables such as booleans, integers and floating point numbers.

MMS supports both a tag-list and hierarchy viewpoint of data. It is possible to build a list of tags within a system. It also has the notion of a hierachy for richer data structures.

A device implementing MMS maintains a data dictionary and a meta-model about the objects in the devices. The protocol supports the notion that a device needs to describe itself. This simplifies the configuration process. In very simple example, an operator workstation could connect to a MMS device and can query the device for its contents. This is different then the
typical approach of manually re-entering tag-lists into a operator workstation, and then manually managing database changes in both devices.

Contrary to the fear, uncertainity and doubt preached by the vendor community, there are vendors that provide tools for developing MMS
communication systems. MMS has been incorporated in popular packages such as:
· Lotus 1-2-3
· Microsoft Excel
· FIX/DMACS
· Wonderware
· Valmet Automation

Major users of MMS are:
· Ford
· General Motors
· Chrysler
· Boeing
· Kansas City Power & Light
· Tampa Electric Company
· Oglethorpe Power
· United Power Association

William F. Hullsiek
Software Engineer
Renewal by Andersen

D

R

#### Ralph Mackiewicz

> Ironically, it would seem to me that commercial interests almost
> guarantee the reinvention of wheels, since each vendor protects their
> wheels (protocols) as valuable intellectual property, so that they can
> compete with others doing the exact same thing. If those protocols
> with their job. Examples of public protocols include all of the web,
> email, time, and other services that make up the burgeoning Internet.

I disagree. I think that it is in the commercial interests of companies to not reinvent wheels and to promote interoperability. This would tend to lower the Total Cost of Ownership (TCO) of
automation equipment which would tend to increase spending by customers and thereby increase both sales and profits. This has been proven countless times in the generic IT industry. I think that the
problem is one of executive vision at those suppliers that take the protocol du jour approach. The people running things at these large
dominant suppliers can't see the forest for the trees. They incorrectly assume that if they don't control the specs (or at least dominate them) then they can't make margin. The problem is that they are not seeing the true commercial interest because they look at their customer base with a static/zero-sum view.

> I certainly do not mean that commercial interests are bad, but I do
> feel that communications protocols might better be considered as
> public infrastructure than as private property. Perhaps an analogy
> could be made with independent railways, each with its own track specs
> (protocols), making engines and cars (controllers, interface products)
> completely incompatible with other railways.

I don't think you could really prove that public ownership of anything is more effective than private ownership. A better analogy is the Internet. Many of the routing protocols used in the Internet started out as (and in some cases remain) the private property of their developers. Cisco Systems came to its position of dominance
because of the innovation represented by their implementation of **proprietary** protocols and the intelligent leverage of this to bring down TCO of internetworking and thereby maximize sales and profits. Other router vendors did not re-invent these wheels...they went along. If they didn't they would get left behind.

The railroad analogy does not hold up for a number of reasons (at least in the US). Most importantly, look at the publicly owned
passenger rail system in the US: Amtrak. Anyone know the accident rates, on-time performance, time/passengermile, etc. on Amtrak compared to other "private" transportation systems? What kind of profits does Amtrak generate? Not a very good example of public ownership if you ask me.

Regards,
Ralph Mackiewicz
SISCO, Inc.

R

#### Ralph Mackiewicz

> Is the spec readily available on the web?

Not the standard itself. You can find an overview and the abstract syntax at: http://www.sisconet.com/techinfo.htm and
ftp://ftp.sisconet.com/outgoing/marketin/mms abstract syntax.txt respectively. The standard must be purchased from ISO or ANSI. The standard number is ISO9506. ISO is at: http://www.iso.ch

> By the way, what ever happended to all the old MAP/TOP documents? Were
> they archived somewhere? Just flushed? Opened up as public info?

GM owned the copyrights on the MAP specs and Boeing owned the copyrights on the TOP specs. These documents did not contain a copy of the standards themselves. They were mostly profile documents and implementors agreements (at least the useful parts). The MMS implementors agreements were later published by NIST and I think they are available from the NIST FTP site (at least they used to be). Anyone needing these can send me an email. I have no idea where they
ended up but I don't think that they have much relevant value anymore. The MAP documents were closely controlled by GM until nearly the very end. After all, they couldn't allow anything as provincial as TCP/IP to be mentioned in there could they? ;-) The UCA documents (future IEC61850) are better descriptions of these profiles anyway. The UCA documents will be published by IEEE as a technical report. Preliminary versions can be found at the above referenced web site.

Regards,
Ralph Mackiewicz
SISCO, Inc.

R

#### Ralph Mackiewicz

> Major users of MMS are:
> Ford
> General Motors
> Chrysler
> Boeing
> Kansas City Power & Light
> Tampa Electric Company
> Oglethorpe Power
> United Power Association

Chrysler should be DaimlerChrysler as the US Chrysler and Ford were not really "major" users of MMS. GM also includes the Vauxhall and
Opel groups which worked independently on MMS based systems. You can add to this list:

- Volvo
- UnionCamp
- American Electric Power
- CFE Mexico
- Duquesne Light Company
- And, just about every utility connected to the electical transmission grid in the US, Canada, and Italy.
- many others that don't allow me to disclose.

MMS is robust, highly interoperable without any vendor specific modifications, allows vendor extensibility without loss of interoperability (due to self-discovery of defined objects), compact, uses standard technology (TCP/IP and Ethernet), is a completely public standard (ISO9506), maps easily to complex data models such as IEC61850 and SP95, and addresses all the functions needed command, control and monitoring applications. However, there are some
disadvantages: It will cost a few hundred dollars to purchase the specification, it will take more than a day to write a DDE server that supports it, and the standard can't be dominated by a single company.

Regards,
Ralph Mackiewicz
SISCO, Inc.