ISO/TC 184/SC 5/WG 1: 2000-September-11/13

National Institute of Standards and Technology, Gaithersburg, MD, USA

Jim Nell, WG 1 Convenor, opened the meeting at 0845 on 2000-September-11.

Attending were:

On Monday, 00-September-11, TC 184 SC 5 WG1 met jointly with CEN TC 310 WG 1 to review documents developed for the joint-work item to update and extend ENV 40 003 and ENV 12 204.

Jim Nell compiled these minutes using notes by David Shorter, Greg Winchester, and Jim Nell.

The minutes of the Kyoto meeting (WG1 N438) were approved as written.

The group approved the agenda (WG1 N440) with the following changes:

• Item 4+: Add presentation by Richard Martin on his work that is relevant to enterprise-reference architectures and enterprise analysis.

No expert who could report officially was present. JJ Michel stated that the Task Force has made no progress on UEML, and that XML extensions may undermine, or mollify the need for the UEML effort. Other WG1 discussion indicated that Peter Bernus is doing research into the usage of partial models, an acknowledged weakness of ENV 40003.

b) CEN TC310 WG1 (See also Item 5 below)

David Shorter CEN TC310 WG1 convenor, reported that he needed a more general mechanism to release CEN-copyright standards to those working on standards development; to wit, the project to update and extend CEN ENV 12204 and ENV 40003. As a result, TC310 resolved that it would delegate to the convenor the right to invite contributors, designate the contributors as experts and add them to a closed document-circulation list.

Kurt Kosanke was unable to attend. Kurt had prepared a CIMOSA report for CEN TC310 WG1 that David Shorter, WG1 convenor, included in document N147 item 9, minutes of the 19th meeting CEN TC310 WG1, 2000-August-23/24, Frankfurt Germany. The CIMOSA report that follows was taken from that report.

"The technical baseline is being updated and updates will be announced on the Web site. They will be publicly available at a cost and provided free to those who have already received the earlier technical baseline. A meeting is scheduled with the GRAI-GIM team to resolve the issue of whether a decision view can adequately be expressed by the FIRO views. Further PR and conference actions are in hand, the main focus of the CIMOSA Association now is on e-business.

"A short report of the joint workshop with CEN TC310 WG1 held in Berlin has been posted on the CIMOSA Web site at http://www.cimosa.de. This also contains abstracts of papers, many with links to the full papers. A fuller report of the workshop (but largely from a framework perspective) is available from David Shorter. Discussion forums have been started on framework and language issues--a further Lotus Notes-based forum on infrastructure is being set up together with Enichem, and a meeting has been arranged in Berlin to discuss ODP and EMEIS relationships. The full workshop proceedings will be produced in combination with other workshops planned in the run-up to ICEIMT ‘02, planned for early Q1 2002 in Valencia."

Standard upper-level ontology (SUO) Richard Martin discussed the IEEE project on Semantic Upper-Level Ontology. He noted that an e-forum is trying to define a reasonable NWIP for a potential IEEE-SUO work item. Those who are doing domain definitions are split into 2 camps:

• Decompositional--logically based, reductionist, and formal
• Organic--holistic and business (reality) based

The work may involve creating meta-level ontologies. The SUO might contain several thousand terms. It is intended to be executable and to have the capability of "redefining itself as it is being examined". Information on the project can be found at the following URL: http://ltsc.ieee.org

Mike Gruninger reported that PSL development fits under a NIST program called "self-integrating systems." Drafts for PSL parts 1 (ontology overview) and 10 (core theories) are being prepared for review by SC 4-SC 5/JWG 8 at its next meeting in October in Charleston, USA. JWG 8 comments on these parts will influence the format for subsequent parts. An XML representation should be available for the SC4 meeting in Madeira. JWG8 will also meet at SC5 in Beijing. A tutorial on PSL is also being prepared, possibly for publication as an informative annex to the PSL standard or as a standalone ISO Publicly Available Specification.

Gary Rathwell presented the features of the Web site established for the Purdue Enterprise-Reference Architecture. He talked about the 4R principles: response, reliability, responsibility, and resolution (of a sample, so many per sec). The mechanisms for placing applications in PERA are principles that designers can use to achieve those 4Rs. The Web site URL is: http://www.pera.net. The page on level-design architecture should be especially useful for current WG1 and SP95 work.

Richard Martin discussed formalization of the Zachman Framework for Enterprise Architecture, which includes the following concepts:

• Formalize the framework approach--not the particular framework
• Naming is as important as structure
• Abstraction versus concreteness and generality versus detail are distinct dimensions
• Framework should provide mechanism, not policy
• Recursion is decomposition and successive refinement, not recurrence
• Multiple views are inherent and essential in system analysis and design
• Roles are ordered, and interrogatives (who, what, when, where, why, and how) are not
• Entire preceding role is relevant for each cell of a frame.

David Shorter pointed out that the effort to revise ENV 12204 will attempt to introduce the Zachman interrogatives.

There are at least wo ways to consider partial models: in terms of the industry sector, or in terms of major domains of enterprise-life cycle or activity. Richard Martin built a series of partial models in pieces of the domains of the enterprise and then related them recursively and linked them to the top level. He has worked with two frameworks trying to fill in cells with different kinds of models, to populate the framework--and this never worked, the cell was always too big. So, he subdivided the domain into smaller domains, and then applied the interrogatives to those.

The framework is ordered on one dimension but the other dimension (interrogatives, corresponding to views) is never ordered. Richard then applied these dimensions to the sub domains, successively adding greater detail until he produced the final result.

David Shorter led the discussion of CEN TC 310 WG 1 N146 (the ENV 40003 revision draft), yielding the conclusions below. These are based on comments and edits re CEN TC310 WG1 N145/147.

1. A specific organization view may not be necessary if business rules are included in a decision view. Or, a decision view is not needed if business rules are included in an organization view. A working decision: Accommodate the decision-view material in the organization view.
2. Figure 1 should be modified to include a dotted line that defines the region covered by the scope of this standard
3. References to Entity Types will be deleted from the framework
4. Life-cycle "stage" will be substituted for life-cycle "phase"
5. The focus will be on business and manufacturing
6. There should not be an emphasis on a "cube" representation
7. Regarding the cube representation, to show a parallelism with ISO 15704 and GERAM, move the PERA face, the life cycles, to the front and move the genericity" to the top and model views to the right side
8. Drop references to orthogonal and substitute independence of the 3 dimensions
9. Define relationship along each axis (genericity and life cycle are "sorted") and research whether a minimum set of relationships can be defined
10. Determine the necessity of "As-Is" in item 8
11. An introductory section should be added to explain why the standard is useful
12. Nothing in the framework precludes change or change management
13. There is a link between "ownership of data" and organization.

David Shorter has the detail of the discussions on revising ENV40003.

Greg Winchester discussed the ANSI/ISA dS95.01 standard, Enterprise-Control-System Integration: Part 1, Models and Terminology, noting that the US National Committee to the IEC had applied for the standard to be fast-tracked in SC 65A. SC 5 has asked WG 1 to review the standard and determine if SC 5 should be involved in the approval process. The issue currently is with the Committee of Action, which met 00-9-15 in Stockholm, and which has to approve a fast track. At a meeting of SP95 in 00-08, Chris Williams was amenable to aligning Part 1 with IS 15704 because dS95.01 would then be more likely to pass a joint ballot. In IEC SC65A, John Childs, BSI, has assigned this project to WG 11. Lynn Craig is project leader and John Childs has been asked to help with IEC-izing it. The committee wants to work with ISO and has invited WG1 to propose changes, which the SP95 committee is happy to receive.

Prior to the meeting, TC184 SC5 WG1 reviewed dS95.01, draft 14. The table below summarizes the comments.

Dennis Brandl reported that the first concern for ISA 95 was the integration of control systems. No one understood the information that was flowing back and forth between the control system and the enterprise, but engineers had the responsibility for the safety of people on the shop floor. Hence the emphasis on domains, where the responsibility rests for the agents that control manufacturing. Did not want see a clerk making a change to data that could generate an EPA hazard.

The second concern was the definition of function in the domain. ISA used the Purdue enterprise-reference architecture as a reference model, as an educational thing, to define activities and information flows. Originally represented information as generic text, than transformed that into an object model. Clause 7 of Part 1 is the core of the proposed standard, and the normative part starts with subclause 7.3, UML models without attributes. Part 1 is now at draft 16

Dennis Brandl then discussed parts 2 and 3 of the S95 standard. Part 2 will add attributes to Part 1, with sufficient detail for XML schemata etc to be derived, The World Batch Forum has offered to start a WG to create these schemata. Relationships are not defined. Part 2 is nearly complete and could be made available to 184/5/1 in December. The ISO-CEN project needs to review the underlying S95 object models to ensure the ENV 12204 constructs are legitimate abstractions. Part 3 is now at second-draft stage, it will be 1.5-2 years before becoming a CD fit for external review.

Dennis also pointed out that part 3 has a relationship with ENV 12204. However, WG1, Dennis Brandl, and David Shorter agreed that part 2 and part 3 have no relationship with ENV 40003, which is a framework. ENV 40003 addresses high-level-business processes; whereas, S95 focuses on mid-level-manufacturing operations, not including product design.

TC184/SC5/WG1 wonders whether CEN TC310 WG1 can abstract the dS95.01 clause 7 and S95.02 stuff back onto ENV 12204 constructs. ENV 12204 constructs should be valid abstractions of S95.01 and S95.02. TC184/SC5/WG1 should co-operate in the development of S95.03. David Shorter agreed to collate some descriptive material for ENV 40003 and ENV 12204 and send it to Dennis Brandl.

The concepts "product segment" and "process segment" are new relative to SC4 and SC5 standards. Resource and equipment modules could be in a specialization of the MANDATE data model. These segments come from situations such as that in oil, where there are intermediate stages that have different values, such as financial, and therefore need to be distinguished; for example, for tax purposes. Hence, the product-segment concept. This is also needed for simulation that supports production planning. Jean-Jacques Michel said that there needs to be consistency of SP95 with SC4 projects in such areas as how to make data exchanges between MANDATE, PLIB.

There are no equivalent constructs (or specializations of constructs) from which process segments could be derived. Similarly, this is true for the related product segments.

WG1 noted a conflict with ENV 12204 relative to "capability", which SP95 uses in the sense of "capacity". More generally, there might be 15 top-level objects to be aligned.

After discussion of the balloting processes involved, WG1 agreed there would be enough time for national positions to be sorted out for any joint IEC ‘CDV’ and ISO DIS ballot. There should be contact in the meantime to sort out the ‘capability’ conflict and any other adjustments of definitions that might appear necessary on a closer reading.

WG 1 then came to the conclusion that SC 5 should indeed be included in the fast-track-balloting process, and proceeded to assist the SC 5 secretary in drafting a letter to the IEC Committee of Action requesting a joint ISO-IEC fast-track ballot. The group drafted a letter of WG1 position and faxed it to the US member of the IEC Committee of Action for the meeting the following day.

Since WG1 agreed that the ISA work will be very useful in testing ENV 12204 constructs, WG1 felt a physical liaison between WG 1 and the ISA SP95 committee would be appropriate. Jim Nell would serve as the WG 1 liaison to SP95, and Dennis Brandl would serve as the SP95 liaison to WG 1. Dennis Brandl would also be included on the distribution list for CEN ENV 12204 work.

Dennis stated that ISA documents are available from the following FTP sites:

• Using Internet Explorer: ftp://standards:g1bp04f9@ftp.isa.org/sp88/
• Using Netscape: ftp://standards:g1bp04f9@ftp.isa.org/standards/sp88

WG1 continued the discussions from Kyoto relative to determining what is the nature of the material to be standardized to enable better manufacturing-process interoperability. We began by considering the information aspects, including people, of applications talking to information aspects of other applications and by reviewing the diagram developed in Kyoto (See the accumulated-knowledge paper).

Members asked whether there is any difference between the notions of interoperability and integration. Ensuing discussion suggested that interoperability is what occurs between enterprises while integration is what occurs within an enterprise. The group then noted that the act of interoperation is essentially the process of setting up an information interaction between processes. This process involves something analogous to choreography; that is, a design or script for a dance. The design of an information interaction is precisely what WG 1 feels it should the focus of new standardization. Interoperability use cases would be very useful in assisting the standardization. A specific use case mentioned was one being developed by NIST for manufacturing printed-circuit assemblies.

Standardization of the choreography will require standards for modeling and representation, capability profiles, ontology, and standards for modeling constructs. WG 1 can leverage the work of other groups, such as CEN/TC 310/WG 1, ISO/TC 184/SC 4/JWG 8, and ISO/TC 184/SC 5/WG 4, so that the project is not too onerous. Nevertheless, WG 1 will have to identify which standards and tools exist and which are needed.

Gary Rathwell reported that a SAP vice president had decided that while the SAP model is OK for an internal system because it can control all the participating elements, it is not sufficient for systems which involve external entities. The SAP assumption is that interfaces could be defined for everything, and when other organizations are involved, such as for out-sourcing or through corporate take-over, you didn’t have sufficient knowledge to define this. This VP left to set up Ariba, which has an XML-based capability for e-commerce. The approach that worked well for the Fluor-Daniel Russian pipe-line project was to make no assumptions about what the remote guy was doing, just that TCP/IP, XML, browsers and Web servers were present. What is it you really need to know to interoperate? The physical things, information about some protocol (TCP/IP), and interfaces described in XML. You don't need to know about what is over there in detail, and you don’t want to know.

Shorter suggested that the relation of an application to standards and to the real world may be represented by as follows:

The model can be either explicit or implicit in the construction of the software, and the functionality items represent the repertoire of behavior required to achieve some internal or imposed goals, specification or whatever. So, to design an instance of interoperability for an application A, we can ignore application A’s real-world bubble because, by definition, it is encapsulated in the model. Further, if A needs to interoperate with another application B, then that fact, and knowledge about B, is also part of A's real world. Therefore:

• The model for application A must be extended to include such facts;
• The functional entities for application A must extended to enable communication and connectivity with B--that is, we are defining application-connection points suggested by Kosanke.

So, can we simplify things to say that an application is, as far as another application and information interoperability is concerned, just an encapsulation of those connection points? The probable correct answer is yes, provided one of those points can provide details of its standards-usage profile and that there is some mechanism for aligning two such profiles between two applications (including references to new external registries. For example: "When I say X, I mean X as defined by URL://www.xyz." This would provide a common point of reference (the easiest case?) for semantics and some kinds of behavior; that is, ontology.

Here is one picture of what needs to happen:

Shorter has a strong recurring feeling that ODP has been over this ground several times--that they have a concept that an application’s behavior was significant only at certain observation points that were required for testing conformance.

Shorter thinks there will be (at least) four sorts of connection points:

• Purely informational: reflexive
• Conversational: with states and protocols, used to establish or tear down bindings
• Bound: where a conversation has established a binding that can thereafter be used by just passing its handle
• Contractual: may be part of or the simplest form of conversational and/or bound, with pre-and post-conditions (similar to Eiffel) and data structures such as signatures and polymorphisms

The question then arises, where do we hold and represent the semantics of those connection points? And the relationships between these as they traverse their various states?

• In a registry belonging to some trusted third party
• In a registry belonging to the owners of one of the applications given a more one-sided relationship.
• In a standard registry contained in all applications and set up by either the querying or responding application

We not are concerned only with 1-to-1 interactions among applications, but also with some 1-to-many interactions. For example, controlled broadcasting of a capability or an intention to withdraw a capability. Incidentally this could be a key part of an application’s instantiation process, even within a single enterprise, so providing for agility etc.

So we could probably use the same interoperability mechanism inside and outside an enterprise. And turning this on its head, does this mean we should introduce the idea of GRAI levels, or rather GRAI decision frames to represent the information (including control) flowing between applications?

Rathwell suggested, re the proposed standard, we might come up with different releases of interface definition, for example:

V1, can exchange data elements

V1.1, can extend and add new data elements to database

V2, can describe the operations that people are doing because people are usually the cause of delays

V3, facility--can you accept 10% more demand?

Al Jones discussed the NIST Self-Integrating Systems project that assumes all communications and infrastructure, such as the Internet and XML are in place. PSL is trying to provide the common point of reference. Want to move away from specifying what the meaning of something is, to how to express what that meaning is. Because, from experience, it takes years and years to get agreement on these specifications, and then it takes a long time to produce the necessary translators. For this reason SAP and Baan have problems with distributed, especially internationally distributed, enterprises. Therefore, predefine nothing other than core concepts and allow the applications to do the definition based on those core concepts. The Self-Integrating-Systems project is investigating methods to reconcile parallel and conflicting developments. A single ontology may or may not work.

Shorter wonders if we can use the idea of incremental, prototyping development. For example, an applet is developed, publishes its capability, then is combined with other applets, maybe by different people, internally or externally, and encapsulated into some new applet functionality.

A key challenge is how to present the capability of an application and how to publish at the appropriate level for the interactions it expects. For this standardization project, WG1 is not concerned with doing the actual interoperation, rather with how you set up the interoperation, the choreography so to speak.

In steps:

• An application wants to express E about X to another application
• The application determines an appropriate level of granularity, considering the applications involved
• Define the context and concepts behind E
• Determine if all of these are already defined
• If so, OK, otherwise publish and enter into a reconciliation procedure

Dela Hostria feels there is a need to consider the persistence of the interoperation, whether it’s purely transitory. Shorter feels that this seems a valid qualifier of the closure of an interoperation act, it’s a qualifier just like granularity. The PERA 4Rs, response, reliability, responsibility, and resolution, the, are qualifiers too. Also consider things such as cost of a transaction over some interoperation binding.

Shorter wants to define a vocabulary for such things as interoperation act (compare speech-act), binding, closure, interception, an interaction. He plans to e-mail material on speech-acts and their role in the choreography process.

WG1 added a Clause 4.3, Infrastructure, to the proposed standard (see outline below). These are the set of resources needed to run the transaction protocols; for example, ontology servers, software-capability profiles, language, modeling constructs, and the choreography itself. Dela Hostria reported that the HLA people are issuing rules to say that if you want to be part of a federation this is what you do. Al Jones added that in HLA, however, there are much weaker semantic bindings, interdependencies, et cetera between the things that are being federated. We have much tighter (semantic?) couplings.

Publication intermediaries will be part of local infrastructure. We need a simple version of the interaction infrastructure at different levels of control--it is much easier at lower levels. Look at the PERA typical enterprise-system architecture on the PERA web-site. We need to define the interaction functionality the application needs to support do accomplish its mission. Will there be groupings of capabilities related to version? Will there be a G1; a G2 which can also do G1; a G3 which can also do G1 and G2, and so on?

The choreography will set up a semantic interface. Do we offer an interface specification? Is that sufficient to allow a realization? We should have a class diagram of the things we are concerned with and their concepts.

There is some idea of infrastructure in HLA, such as for exchange of information and federation. The US Department of Defense is starting work on an agent-mark-up language. Also look again at FIPA work, Foundation of Intelligent Physical Agents. dela Hostria suggested a concept of capability-description format.

Can we assume a central ontology server, or a library of ontologies? How are different responses for different libraries to be reconciled? Is there any role for BSR? WG1 could produce the standards as a broad statement of requirement plus a specific demonstration to show how it would work for the case of a single ontology. The multiple-ontology reconciliation is a research issue.

There was general agreement that WG1 can do the choreography part and define the requirements for infrastructure--some part of which will already exist, others not. Al Jones suggested that we could have standards for formal modeling, how a formal model is represented to the work on KIF or whatever, and representation of models in standards constructs (a UEML?). The PERA Web-site has a generic-industry process matrix that is a high-level indication of the generic-conceptual space that is needed, but that must be qualified by kinds of industry.

Might there be a possible workshop in self-integrating systems under ICEIMT'02? Include automation objects and MES maybe?

Em dela Hostria informed WG 1 members of the IEC Sector Board 3 decision to hold a workshop on automation objects. As this workshop has yet to be held, WG1 wondered whether Sector Board 3 envisions a workshop audience beyond its constituency. If so, it was questioned whether such a workshop and one of the ICEIMT'02 workshops could be combined.

The next WG 1 meeting was tentatively scheduled for the week of 12 December 2000 either in London (BSI) or Paris-La Defense (Maison de la Mecanique). WG 1 also will have the opportunity to meet on 01-May-14/16 in Beijing, China, preceding the scheduled SC 5 plenary meeting on 01-May-17/18.

Jim Nell adjourned the meeting at 1600 on 13 September 2000.

Notes prepared by: David Shorter and Greg Winchester, WG 1 Secretary,

Compiled and edited by: Jim Nell, WG 1 Convenor

Title: Requirements for manufacturing-process interoperability

WG1 realizes that there is technical development required to effect this mechanism for interoperability improvement. The standard(s) WG1 envisions will define the process of establishing a desired communication rather than defining the communication itself. In addition, the standards should be written to enable the entire envisioned interoperability capability by staying independent of specific technologies that may be used to improve interoperability performance. The standard will introduce concept of an interoperation act--the process of setting up the ability to have an interaction or communication. Some parameters of the interoperation act will be persistence, cost per transaction, speed, the 4rs of PERA.

4.1 Capability (Capabilities that the standard will prescribe)

4.1.1 Identify capability (methodology, declare context (usage and applicability, and regime of interoperability))

4.1.2 Extract

4.1.3 Extend

4.1.4 Register, publish

4.1.5 Compare

4.1.6 Constrain

4.1.7 Organization of capabilities

4.1.8 Represent (shall include pre and post conditions)

4.1.9 Quality of service

4.2 Protocols (The kinds of transactions that can happen. Things to do with capabilities)

4.2.1 publish (supplier)

4.2.2 Browse (customer)

4.2.3 Interrogate

4.2.4 Invite

4.2.5 Offer

4.2.6 Assess match

4.2.7 Do match

Complete

Partial (extend or redefine)

None

Qualified (match if)

4.2.8 Establish communication (closure)

4.2.9 Quality of service management

4.2.10 Exit (Reset)

4.3 Infrastructure (The set of resources needed to run the transaction protocol)

4.3.1 Software-capability profiles

4.3.2 Ontology

4.3.3 Language

4.3.4 Enterprise-Modeling Constructs

4.3.5 Choreography of a transaction

4.3.6 ...

Annexes for scenario, use cases, and collaboration diagrams for protocols (for example, swim lanes)