Assumptions about the environment:

• The necessary infrastructure is in place
• There are two players involved in transactions, a customer and a supplier. Customers and suppliers have software applications, each of which has its own ontology inside that conforms to international standards, hopefully those being planned by the TC184 SC4/5 JWG8 PSL-ontology project.
• When a manufacturing enterprise engages in these transactions there are several actors whose role need to be defined and understood; such as, enterprises, applications, processes, and systems.
• There is a real-world domain and an information domain in processes that interact
• There are information models representing the information aspects of those actors.

Definitions: for this standard WG1 considers the following to define the actors and the transactions:

Application: Software system or tool

Enterprise: Collection of processes that share common goals regarding its product or service output

Information aspect: The part of an application that communicates with its environment

Integration: Communication that occurs within an enterprise

Interaction: When the information aspect of an application transfers information to an information aspect of another application

Interaction capability: The degree to which an application can interact, a function of the technology level of the applications

Interoperability: Sharing necessary information among the information aspects

Interoperation: Communication that occurs between enterprises

Interoperation act: The process of setting up the ability to have an interaction. Analogous to choreography--a design for a dance

Process: Collection of software, information models, and physical systems that perform a function

System: Collection of real-world items organized for a purpose

Information exchange: WG1 feels that although one can envision exchanges, or interactions, such as process-to-process, system-to-system, and enterprise-to-enterprise, none of those will be meaningful to us because of imprecision. The standard is to enable more effective interaction signals between modeled business processes. Therefore, we will consider the only meaningful interaction to be information aspect-to-information aspect, and this will occur between customer and supplier applications; for example, queries and responses.

Prescription: With the standards under development, WG1 wants to move away from specifying what something means and move toward specifying how to determine what something means. The challenges are inter-enterprise, intra-enterprise, and ERP-to-extended-enterprise types of transactions. (See the diagrams Gary and David) WG1 realizes that there is technical development required to effect this mechanism for interoperability. The standard(s) we envision will define the process of establishing the communication rather than defining the communication itself. The standard should be written to enable the entire vision by staying independent of specific technologies that may improve incremental performance.

Capability: Process capability is defined in terms of the potential function. Capability is expressed and represented as information about the process and what it can do. The standards should define that an application should contain a standard way of representing "What I do and what I need"; so that there could be a dialog theme such as: "I can do Q but I need E, F, and G". Each application needs to be able to express its capability in a standard way. Application A needs to be able to express its capability and what it needs from another application B; such as, function, decision capability, granularity, context and concepts that underpin the function of the application. The standard should prescribe the choreography for setting up the agreed upon parameters of the planned interaction.

The capability concept comprises several aspects of enterprise-process interoperability.

• Capability expressed by an enterprise-level or business-level process to a process inside of the enterprise or outside. The actors are: customer = procurement, and supplier = sales. This involves activities such as advertise, initial contact, negotiate, contract, and terminate.
• Capability expressed by enterprise-level or business-level to the factory processes. The actors are: customer = procurement, and supplier = manufacturing process. This activity is seeking information the customer or supplier will share about its manufacturing processes. Involves such functions as quality, cost, repeatability, reliability, and shipping information.
• Manufacturing-process capability as expressed to another manufacturing process. The actors are: customer = internal business process such as scheduling, and supplier = factory-floor manufacturing process. This involves operating the process, accomplishing the function, data needed and supplied, personnel skill profiles, equipment features and profiles, tolerances, time, and process status.
• Capability expressed to represent the physical portion of systems within a process. The actors are: customer = factory-floor-manufacturing process, and supplier = factory-floor-manufacturing process or an enterprise-level process. Involves interconnections, special power requirements, bandwidth, medium, data rate, communications profiles, sensor and actuator information.
• Capability expressed to represent the logical portion of systems within a process. The actors are: customer = factory-floor-manufacturing process, and supplier = factory-floor-manufacturing process or an enterprise-level process. Involves languages, software, session profiles, and installed versions of those things.

In TC184 SC5 three working groups will standardize constraints regarding expressing capability.

• WG1: Define the rules for the process, the choreography, of advertising, contacting, resolving terminology, negotiating, contracting, obtaining manufacturing information, obtaining status, and termination of the interaction. Suggest how the rules could be implemented in vendor products. (All five capabilities above are in scope.)
• WG4: Define the rules to express manufacturing-process capability during the process operation. (The third capability above is in scope.)
• WG5: Define the rules to set up the necessary physical and logical transactions. (The fourth and fifth capability above are in scope.)

Interoperability and Integration: Is any difference between the notions of interoperability and integration. WG1 feels that interoperability is what occurs between enterprises while integration is what occurs within an enterprise. However, 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.

Ontology: The standard should require, and suggest a method of accomplishing, each complying application to set up a common domain of meaning based on the individual local ontology that is to be contained within each application. The ontology format will be specified in the standard.

ISO TC184 SC5 WG1 needs an ontology to do or contain the following:

• Have negotiated or mediated capability
• A standard way of creating a new ontology from customer and supplier local ontologies
• Consensus on semantics of the ontology
• Consensus on the methodology of representing of the ontology
• Tools to support and extend the ontology
• Concepts such as qualities, properties, and characteristics
• Language with formal syntax and has notion of consistency and equivalence
• A way to ascertain completeness

The following are ontologically necessary to achieve self-integrating system

• Flexibility, extendibility, capability to mediate to create needed characteristics
• Method to create the temporal ontology
• Way to agree on semantics between two systems
• Standard way for applications to represent their own ontology
• Terms in the ontology: qualities, properties, characteristics, for example timed or located
• Language with formal syntax and has notion of consistency, equivalence, and completeness
• Ways to assure compliance and conformance
• Characteristics or negotiation acts increasing levels of commitment
• Static--Is a meaningful exchange possible? (Use IDEF, PSL, KIF to give model information)
• Dynamic--Is exchange sufficient to achieve behavior desired?

• Quality of performance--Can we resolve the differences?

• Fault-recovery capability
• Behavior capability to fulfil objective

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.

Example Interaction: An application needs to be able to set up an interaction by doing the interoperation act, wherein the application sets up the parameters of a transaction; such as, persistence of information in a transaction, the cost per transaction, the technical level for the transaction, and necessary speed. Then, decide, or already know, what information one wants to expose. Define the context and concepts behind application A. See if there is a domain of common understanding by comparing the application ontologies and creating a mutual ontology somewhere. Differences are resolved by using such techniques as the definitions, using the process-specification language, consensus, and a one-off. Invoke a process that determines if the combined domain is sufficient for the customer's needs. Then begin a dialogue; such as the one that follows.

[A] Can you do Q?

[B] Yes, provided I get E, F, and G,

[A] Well, I only have F, G, and J can you do ~Q?

[B] Yes

[A] When and how much?

[B] Response

Reevaluate to see if ~Q is good enough. Then do the interaction. WG1 standards do not constrain the communication part of the interaction.

Web Search Engine: There should be a publication intermediary as a part of the interaction infrastructure, such as a World-Wide-Web-search engine. The standard should require or recommend that inter-enterprise exchanges be administered by Web servers, and that the server gets information from data systems that may include factory-floor processes.

Levels of Interaction: High-level and low-level interactions have different dimensions. The higher level interactions; such as between MES or ERP systems, have larger granularity, richer semantics, and fewer transactions. The lower -level interactions, such as between factory-floor processes, have more transactions, smaller granularity, and a less rich semantic content.

The standard must recognize that there may be various levels of capability for performing the interoperation act and for the interaction itself. Therefore, the standard(s) must allow for eventual addition of newer technology in a way that does not break the standard process for interoperability. The standard should offer enough for some user to create a sufficient interface and accomplish a satisfactory interoperability. If the planned standard can not do that then WG1 should not publish the standard.

To prepare the standard WG1 should start with a use case, perhaps what information is needed to fill the matrix boxes provided by Gary Rathwell.

Metric for success. Interoperability, as with integration, is a process not an end. Improvement in interoperability will always be possible. A successful interoperation is an interaction that elicits the desired behavior within parameters deemed important by humans operating the enterprise.

Interoperation among processes: The figure below was originally prepared by Yoshiro Fukuda to help the working group sort out the various concepts of process interoperability and to allow us to focus on the parts that would be standardized by this working group. The Convenor has updated the graphic to include results of subsequent group discussions.

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

The model can be either explicit or implicit in the construction of the software, and the functionality items on the illustration represent the repertoire of behavior required to achieve some internal or imposed goals, specification or whatever. 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, are 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 be 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: http://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:

Note: 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 (What about any-to-any?). 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.

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?

Self-Integrating Systems: Al Jones discussed the NIST Self-Integrating Systems project that assumes all communications and infrastructure, such as the Internet and XML are in place. 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 about the former, 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, we would prefer to predefine nothing other than core concepts and prescribe how the applications must do the definition based on those core concepts. PSL is trying to provide the common point of reference with extensions of core concepts in a specific domain. 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. As stated previously, 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

Other topics: Em 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, binding, closure, interception, an interaction. He plans to e-mail material on speech-acts and their role in the choreography process.

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.

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.

A paradigm that will further process interoperability--use cases and scenarios

WG1 envisions a model that does not set specific limits to everything. Rather, consider a combination of standards and tools that would force enterprises to analyze and document, perhaps electronically on line, what they do; and then operate their enterprise accordingly. Lower-level standards, such as the Open-systems interconnection, would still define infrastructure interfaces. Either the querying or the supplying process could indicate which protocols or standards apply. The processes also would present information about the process capability. Standards would define the choreography of this introduction process. Thus, an enterprise shopping for a process would be able to evaluate, on line, that a candidate process meets both quality and capability guidelines and that they conform to listed interface standards. Either enterprise could then advise its software to make any needed adjustments to its software applications, establish a relationship, and operate in an acceptable (to both parties) level of integration. This will not always be the most perfect information transfer imaginable, but the best considering the technology encountered.

The strategy is to create a family of software tools and standards that apply to interoperating enterprise processes. ISO TC184 SC5 WG1 generated several process-information-exchange use cases to help envision what would be the nature of the communications necessary, where the processes would interface, and the standards involved in such exchanges.

1. Publishing a capability (an interface) to unknown clients.
   Raises issues of semantics, taxonomy, representation, costs, and service qualities. Also, this case involves a looser coupling than in 2 below.
2. Assume that a customer exists with a standard ontology. Negotiating and establishing an interworking mechanism, possibly with help from intermediaries.
   Implies contracts, modalities such as inventory replacement, and situation where both parties benefit. This case has a tighter coupling than in 1 above.
3. Establishing a low-overhead version of 2, once trust has been established. Implies presence of tokens, encryption, and authorization. Capability to select, invoke, abort, terminate the process on the fly
4. a. Executing the interworking mechanism of 2 by having signals for interoperability to happen. Implies time horizons, quantities, and description of behavior; such as, characterizing machine state
   or
   b. Executing the interworking mechanism but adding static or dynamic constraints, such as interfaces with Open-distributed Processing; for example, motion control and mechanical assembly.
5. Monitoring the interworking, within an agreed envelope of quality of service(s), perhaps with third party involvement. Implies contracts monitoring, exceptions, and performance.

Other use-case points.

• Use cases 1 and 2 are concerned with the what; use case 3 with the how, and use cases 4 and 5 with the do part of process communication.
• A possible 6th use case might emerge as a result of 5. That is the evolution and encapsulation of business processes into a new business process with newly exposed service interfaces.
• A further use case topic is to define how an organization would make use of the standard(s) that will come out of this work. This theme will be incorporated into each use case.

Use Case 1 expanded: "Publishing a capability"

Actors and Resources:

Marketing function, business processes (inputs and outputs), external view of process model, language, WorldWide Web, database, and server.

What happens:

1. Extract or select a needed capability.
2. Represent the capability in an understandable structure. Implies language(s), customer vocabulary, codifying, key words, arrangement (in the sense of organization of parts), registration, and notification.
3. Use the represented capability for the requirement in 1 above.
4. Publish. Implies implementation
5. "How to use us" and/or "How we do business". This implies modalities and qualities of service such as costs accuracy, and delivery. Note that publication could be for human review and/or machine review.

The other use cases should be expanded to expose the scope of technology, standards and capability required for self-integration.

Scenarios

While the main focus of the self-integrating project envisioned is discrete-parts manufacturing, other scenarios might suggest something that would be useful to add to the manufacturing model. In general, a scenario sets up as follows. Software system A is deployed on the Internet intending to interoperate with system B. Focusing on semantic interoperability, component A sends an initial query message to B identifying the preferred communication and content languages, as well as the adopted semantic definition for the languages. The languages and semantic definition are accessible in the environment of each system. Systems A and B interact to negotiate appropriate languages and neutral semantic definitions. During the negotiations, the two systems adjust, adapt, and/or select appropriate parameters or components to establish semantic interoperability.

Title: Requirements for manufacturing-process interoperability

Note: 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 4 Rs of PERA--response, reliability, responsibility, resolution.

Concerned with how the requirements are identified, designed, specified. It will cover the complete lifecycle of the capability of the interoperation.

Concerned with how to present the capability of an application and how to publish it at the appropriate level for the interactions it expects. This will include activities such as extract, extend, register, present, compare, constrain, organize, represent (including pre and post conditions, and quality of service).

This will specify the interoperation acts necessary to achieve effective interworking.

Concerns the protocols for the transactions that need to happen. This subclause defines the functionality of each of these transactions, including publish (done by the supplier), browse (done by the customer), interrogate, invite, offer, assess match, negotiate, establish communication (closure), manage quality of service, exit (reset)

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.

This will identify the set of services needed to run the transaction protocol; for example, ontology servers, software-capability profiles, language, modeling constructs, and the interoperation acts that will set up the semantic interfaces.