Good Morning. My name is Neal Laurance, and I work for Ford Motor Company in the United States. I am here today representing ISO TC 184/SC 5. TC 184's title is Industrial Automation, and SC 5's title is Communication and Integration. SC 5 has four working groups; Working Group 1 and Working Group 4 are separately represented at this conference, and I will not describe them further. The work of Working Group 2 is communication appropriate to industrial automation. Working Group 3 is concerned with industrial vocabulary, While none of these working groups define a data modeling language, they do use data modeling languages in developing their standards, and thus provide requirements for such languages.
Working group 3 has developed an industrial vocabulary, drawn largely from the definitions in a variety of ISO standards. While it does not have any relationship to data modeling languages today, it may make use of the results of the work of the BSR group.
Working group 2 is responsible for several standards relating to industrial communication. One of its standards, ISO/IEC 9506 - Manufacturing Messaging Specification, makes use of a formal data modeling technique. ISO/IEC 9506 became an standard in 1990; it is now in revision for a second edition. Its history illustrates several requirements on data modeling languages and problems in using them.
ISO/IEC 9506 was created as part of the MAP project; it was designed to provide a vendor neutral communication format for messages passed between typical devices found on a manufacturing plant floor. These include robots, numerically controlled machines, programmable controllers, "hard" automation (e.g. transfer line controllers), and plant floor control computers. The situation in manufacturing automation at that time (i.e. the mid 80's) was an industrial tower of Babel. Each area of automation had its own idiosyncratic way of describing things, and variations of terminology among the equipment vendors added to the confusion.
The goal of the MMS team was to define a set of messages, requests and responses, and to define the meaning of these messages in terms of behavior of the responder. Meaning, however, was difficult to come by, given the diversity of language employed in the various component industries.
In an attempt to find common ground, the MMS development team decided on a strategy of using object modeling techniques to abstract away from all the differences in approaches between these devices. The MMS team created a message standard for an abstract device, allowed specializations of this abstract message set to apply to each of the device types. Thus, MMS is a multi-part standard; parts 1 and 2 define the core abstract message specification; parts 3 ff. describe specializations of this model and message specialization for each of several application areas, robots, NC machines, programmable controllers, etc.
To support this approach, MMS used an informal modeling technique, loosely object oriented, but basically an entity-relation method. At the highest level, the communicating node (server) is described as a virtual manufacturing device (VMD). Subordinate to this object, other objects are defined, domains, program invocations, variables, variable lists, semaphores, event conditions, etc. Each such object is described in terms of its attributes, the constraints on the objects because of the attributes values, and the relationships between objects.
MMS must be counted as having had mixed success. In its area of application, manufacturing automation, there have been fewer implementations than one may have hoped. However, the unifying language that it developed, that of the VMD and its components, has largely replaced the vendor proprietary languages of a decade ago. That is, MMS has influenced the human language of communication in manufacturing much more than the computer communications.
MMS has had success in areas not anticipated; at this time, it is the system of choice of the Electric Power Industry in this country, and may well become the system of choice world wide.
As mentioned above, MMS is currently in revision. In its original form, it employed ASN.1, ISO/IEC 8824, as the method of specification of the message protocol; it used OSI conventions for the service interactions. Since that first publication, ASN.1 has itself been revised and an object formalism added to the standard. ISO/IEC 8824 now consists of four parts, the message protocol specification, the object modeling specification, the constraint specification, and the parameterization specification. For its revision, MMS replaces the informal specification of the first edition with a formal data model using the object modeling techniques of ISO/IEC 8824-2. The revision is currently out for its CD ballot.
Besides being a member of SC 5, WG 2, I have also been active for the past 5 years in SC 4, the STEP working group. I wish to take a moment to reflect on the similarities of experience between these two groups, and the implications this has for data modeling languages.
In SC 5, an abstract language, MMS, was created for describing messages passed between abstract devices. Specializations of this language appropriate for specific devices found in a manufacturing environment were created by separate committees composed of experts in the field of these devices. This was to be done by specializing the object models found in the base document to apply to the area of application. The people responsible for the specialization were the members of the application area committee. The rules governing the creation of these specializations (that is, constraints on the application standards committees), written in English, were contained in a normative annex to the base document.
In SC 4, the base modeling construct was an generic model appropriate to all product data. The STEP methodology involved groups of application area experts developing a model appropriate to their area in a neutral form and then having that model interpreted in terms of the generic model by modeling experts. The method of relating these two forms is incompletely documented, and is still somewhat of an art.
In both cases, the abstract modeling language, (ASN.1 in the first case, and EXPRESS in the second), while not completely satisfactory, proved more than adequate to the task demanded of them. The weakness in both cases comes from the mapping process, relating the general abstract specification to the specific concrete case. My friends in this community tell me that this is not surprising; interpretation or specialization is at its core a matter for human judgement. Human judgement is itself a metaphor for aesthetics, i.e., something other than technology.
In retrospect, this result should not be surprising; it is as old as the philosophers. Plato avoided this question by declaring that the real world was but a shadow of an ideal world painted on the wall of a cave. This ideal world is one that is fully captured by our data modeling techniques; the real world remains an imperfect shadow.