WG1 is developing a new standardization approach for enterprise representation. In the new suite of standards covering process interoperability, WG1 will be less prescriptive about representing enterprise processes and more prescriptive about major components and attributes that should exist in the enterprise that would improve interoperability. The new standards will define how an enterprise process can communicate, in a standard way, information about how other enterprise processes can communicate with it. Following is new-work-item-proposal information for the first standard in the series and description of other standards that are planned for a suite of standards about process interoperability.

WG1 plans to establish a project to do preparatory work that employs use cases to generate a suite of standards designed to improve manufacturing-enterprise-process interoperability. To define the project, WG1 has assembled this paper that includes:

• The title, scope, purpose, and justification of the new standards suite
• A problem statement that defines the problem to be solved
• Why industry needs a new approach to process interoperability
• The use cases discussed above
• A road map of the planned standards that shows a logical order of development, any research or development needed on technology before standards development, and testing required after standards development.

New-work-item proposal information on the first planned standard:

Rules for manufacturing-process interoperability

Scope

This information-technology standard will give guidelines, rules, and quality criteria for enterprise-process-interoperability solutions.

Target date

2002-12-31

ISO 14258 Concepts and rules for enterprise models

ISO 15704 Requirements for enterprise reference architectures and methodologies

CEN ENV 12204 Constructs for enterprise modeling

Liaison organizations

OMG, JTC 1, TC184 SC4, Software-development consortia

Need for coordination within ISO and IEC

TC184 SC4 WG8; Mandate projects

■ Proposed project leader (name and address): Jim Nell, NIST, nell@nist.gov

Concerns re known patented items--none

Purpose and justification

The purpose of this standard is to describe the domain of a suite of standards with respect to achieving the best possible process interoperability.

1. Specific Aims: This standard will describe a process and underpinning meta data that an enterprise can tailor and deploy to determine the simplest set of protocols that must be in place to negotiate and achieve satisfactory and purposeful inter-process communication. Application software would be required to have the capability to determine, in a standard manner and on a case-by-case basis, the method by which querying and responding processes can communicate. The object is to communicate to the best degree possible when considering the process applications, and the versions of those applications, that are in place. The applications will have the capability to generate the required mechanism for accomplishing this.
   
   The standard will help to resolve interoperability issues by defining a realistic role for international standards in this area. Ensuing standards will help vendors create software products that enable the information transfers required by any organization of processes. Accomplishing these transfers will provide a path for enterprises to approach higher levels of integration by defining guidelines for designing new enterprises that can operate in a more integrated mode, and for creating enterprise models. The problems that hopefully will be resolved are discussed in attachment A to this NP, Enterprise representation: a different paradigm for designing process-interoperability standards.
2. Beneficiaries: The main beneficiaries from a standard such as the one proposed would be software vendors, internet-service providers, enterprise modelers, and industrial users in a distributed-manufacturing mode--especially small-to-medium-sized businesses looking to be a supplier in virtual-enterprise situation. A set of requirements as those to be described herein would increase the demand for a consistent set of enterprise models.
3. Feasibility: A key to the successful establishment or general application of the standard will be the participation, review, and acceptance within the application-software developers and users.
4. Timeliness: The state of technology on which this suite of standards will be built varies. WG1 has assembled a plan, Table 1, that outlines the various standards needed and has indicated on that plan those areas that require research, development, and those that are mature enough for standardization.
5. Urgency of the activity: A suite of standards that further process interoperability is planned. Table 1 shows the progression of standards development.
6. The benefits: The suite of standards would greatly facilitate the transfer of information, and ultimately the transfer of product, among manufacturing-enterprise processes.

People or machines analyze, design, simulate, and operate enterprises with tools. To justify the investment of the tool builder and to make the tool cost reasonable, the tools must be compatible so that more than one enterprise can use them. The tools must be extensible, migratable, and interoperable so that one enterprise can evaluate virtual-enterprise opportunities, select the most favorable, and then hook up to the selected enterprise. The other enterprise will be operating, but using tools at a different version and technology level. The problem is to determine which components of inter-enterprise transactions should standards constrain. Should they constrain model structure, model content, interfaces between models, and/or known hook-up points so that the software knows with what it dealing? What standards need to be in place to increase the market for tools, thereby justifying development costs for tools that conform to the standards?

This issue is difficult because the resolution lies in a range between a need for no, or few, standards and a need to standardize and constrain everything. It is often the easiest and least-effective solution to a computer-compatibility problem to try to standardize everything. The loss of user delight, the loss of opportunity to use tools especially designed for the job, and the lost opportunity for technological improvement is enormous--and it would stay that way because standards always consume more time to develop than the technology that standards are attempting to constrain. Shortening the time it takes to make standards is not necessarily a good idea. Imagine a world with many easily and hastily constructed standards.

The only standards in this new approach would be the basics, such as ASCII and a common nomenclature. The National Industrial Information Infrastructure Protocols Consortium Project, NIIIP, has a mediated architecture is probably the way of the future rather than standardizing everything. The standards will change much more slowly than the technology improves. This would stifle innovation. ISO TC184/SC5/WG1, the ISO group responsible for enterprise modeling and architecture standards, will analyze the real need for enterprise-integration standards by approaching the topic from a mediated-architecture viewpoint.

WG1 envisions a standards model that does not set specific limits to everything. Rather, such a standards set would force enterprises to analyze and document, perhaps electronically on line, what they do; and then operate their enterprise accordingly. Lower-level standards would still define interfaces and the supplying process would indicate which ones apply, together with the set of information they present on line about their processes. This way, an enterprise shopping for a process would be able to evaluate, on line, that a process meets both quality and capability guidelines and that they conform to acceptable interface standards. The shopping enterprise could then advise its software to make any needed adjustments to its enterprise models (function, hardware, software, communication, and information), establish a relationship, and operate at a level of integration that is acceptable to both parties.

WG1 plans to not standardize the enterprise, parts of the enterprise, the information transferred, its products, or its processes. WG1 does envision standards for product descriptions, for example STEP, and the process descriptions, for example CEN ENV 12204 extended. WG1 envisions standards covering the interfaces and the nomenclature, and the formats and allow the enterprise-tool builders to use these standards to design software in such a way as to allow the processes to communicate.

The enterprise model will allow more consistent modularization so that enterprises can interchange pieces of the models. The models will ameliorate the need to develop the entire system at one time. Simulation will be possible allowing evaluation of interoperation with interenterprise entities and evaluation of systems with differing granularity. Enterprises will be able to plan migration paths more effectively. Because information will be a separate asset, changing applications will be possible without re-entering information about the products and processes unnecessarily. Enterprises can define paths to make the product and process information tie logically into enterprise goals, strategies, capabilities, and business rules. The models should be scalable so that a high-level model is essentially the same as a lower-level model--that is, use the same modeling constructs for all levels.

A WG 1 strategy is to create a family of standards that apply to interoperating enterprise processes. Several process-information-exchange use cases were generated to help the group envision what would be the nature of the communications necessary, where the processes would interface, and the standards involved in such exchanges. The use cases are:

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. Negotiating and establishing an interworking mechanism, possibly with help from intermediaries.

Implies contracts, modalities such as inventory replacement, and two-sided purpose. 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.

4a. Executing the interworking mechanism (e.g. state-machine characterization). Implies time horizons, volumes, and description of behavior (?DNS).

4b. Executing the interworking mechanism but adding interaction modalities such as ODP handoff; for example, motion control.

5. Monitoring the interworking, within an agreed (envelop of) quality of service(s)--perhaps with third party involvement. Implies contracts monitoring, exceptions, and performance.

• 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 important use case was identified by Em dela Hostria; that is, how will an organization make use of the standard(s) that will come out of this work. This theme will be incorporated into each use case.

To date there has been time to expand only one of the use cases. The others will be expanded later.

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

1. Extract or select a needed capability.
2. Represent the capability. Implies language(s), customer vocabulary, codifying, key words, arrangement (in the sense of organization of parts), registration, and notification.
3. Map 1 to 2 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 standard projects listed in Table 1 were developed at the WG1 Brisbane meeting. Further discussion at the London, Ontario, meeting identified additional areas for standardization. These are software-capability profiles (an NP drafted by the SC5 study group on manufacturing software capability profiling, SC5 N603) and the Process-specification language being developed at NIST in the U.S. Comments received to the earlier version of this document have been incorporated into this version. The net effect of these comments on this document is that some of the standards needs identified at that meeting have been combined into the first standard for the following reasons:

• There should not be another general and high-level standard from WG1
• The functionality of some of the proposed standards will fit within the new scope for the first standard
• Many of the requirements that would be in those standards are methodology and, therefore, should not be standardized
• Many requirements are, or should be, covered in other existing standards.

WG1 envisions standards covering the interfaces, the nomenclature, and the formats and allow the enterprise-tool builders to use these standards to design software in such a way as to allow the processes to communicate.

R = Research, D = Development, S = Standard, T = Testing Services

In the original version of this plan this standard was to be guidelines, philosophy, and an overview of the standards suite planned. Comments indicated that this standard should be more specific to the point of process interoperability.

This standard will prescribe a metamodel for determining where the necessary interoperations must occur and for describing the mediation method. This standard will contain rules for determining the simplest set of protocols necessary to negotiate and achieve satisfactory and purposeful inter-process communication (See # 5 and 6, Table 1). Compliant application software would be required to determine, in a standard manner and on a case-by-case basis, the method by which querying and responding processes can communicate. The object is to communicate to the best degree possible when considering the software applications that are employed, and the versions of the applications, and to generate the required mechanism for communicating. The standard will resolve interoperability issues by defining a realistic role for international standards in this area. Ensuing standards will help vendors create software products that enable the information transfers required by any organization of processes. Accomplishing these transfers will provide a path for enterprises to approach higher levels of integration by defining guidelines for designing new enterprises that can operate in a more integrated mode, and for creating enterprise models.

The main beneficiaries from a standard such as the one proposed would be software vendors, internet-service providers, enterprise modelers, and industrial users in a distributed manufacturing--especially small-to-medium-sized businesses looking to be a supplier in virtual-enterprise situation. A set of requirements as those to be described herein would increase the demand for a consistent set of enterprise models.

Expected impact of resultant standard:

• The new standards set would allow enterprise processes to analyze and document, on line, what they do and how they communicate; and then operate accordingly. Lower-level standards would still define interfaces
• The supplying process would indicate which standards apply in each communication, as well as the set of information they present on line about their processes.
• An enterprise shopping for a process would be able to evaluate, on line, that a process meets both quality and capability guidelines and that they conform to acceptable interface standards. The shopping enterprise could then advise its software to make any needed adjustments to its enterprise models (function, hardware, software, communication, and information), establish a relationship, and operate at a level of integration that is acceptable to both parties.

The consensus of the comments received is that no new standards are needed for these topics. These two standards deal with reusable, partial models. That means they are models. This is a topic supposedly covered by ISO 14258 for enterprise models, ISO15704 for partial models, and CEN ENV 12204 for modeling constructs. If these standards need to be expanded to sufficiently constrain reusable enterprise models, then we should update the existing standards. CEN TC310 WG1 plans to extend CEN ENV 12204 and to coordinate their work with TC184 SC5 WG1.

There are parts of an enterprise-engineering methodology that may be common to any otherenterprise-engineering methodology, parts that are specific to a type of industry, to a commonly experienced type of change, to a company, or to a project. Since a task team normally shares a methodology for a specific task or purpose, and there may be many good methodologies to accomplish a particular task, it is not desirable to try to force a standard methodology. WG1 should be careful not to prescribe how to represent processes, how to do the modeling, or how to engineer enterprises.

Profiling software capability would be a useful standard that fits into the new and developing TC185 SC5 WG1 process-interoperability-standards- suite. With so many versions of the same tools and choices of competing technologies, it is difficult to imagine that any set of processes will be using the same version of any tool--software, hardware, communications protocol, or information format. Standardizing these tools and freezing the technology in not is anyone's best interest. Two processes attempting to exchange information, then, can really only hope to communicate to the degree that the functionality that the least capable tool permits.

If a way to represent the capability of software, not the software, was successfully standardized it could provide a way for processes to query each other in the prescribed way. This proposed standard would enable the best possible inter-process or inter-application communication to be accomplished, based on the implemented capability available between the processes. As processes become more distributed as with virtual and extended enterprises, this standard will be increasingly more useful.

The normative requirements in this standard would resolve issues from two viewpoints: usability and interoperability. User requirements that might be addressed are:

• Assembling a new functionality
• Selecting appropriate software
• Substituting one software component with another
• Migrating to another platform
• Managing software inventory
• Certifying software to a capability profile;
• Distributing software to the mass market
• Managing manufacturing changes
• Registering new software

Interoperability issues that might be addressed by this standard are:

• Ability to describe software in unambiguous terms to enable a common understanding
• the characterizing of the business benefits delivered by software components
• Ability to find enabling candidate software components automatically using things such as search engines. This gives rise to sub-issues such as the business and technology contexts, and the process and data taxonomies
• Expressing the dependencies of one software component on other application or on other operating-system components
• Management of the implications of change

In all types of communication, the ability to share information is often hindered because the meaning of information can be drastically affected by the context in which it is viewed and interpreted. This is particularly true in manufacturing because of the complexity of manufacturing information and the need to exchange this information among various software applications. Different manufacturing functions may use different terms to mean the exact same concept or use the exact same term to mean very different concepts. Often, the loosely defined natural-language definitions associated with the terms contain so much ambiguity that they do not make the differences evident and/or do not provide enough information to resolve the differences.

The goal of the PSL work is to develop a language for specifying industrial processes. Much of the work within SC5 deals with the definition of and exchange of information at the shop-floor and enterprise levels. However, SC5 defines an enterprise by the processes it performs. The PSL primary purpose is to provide a set of concepts and definitions that would allow one to describe process information, both at the enterprise level and at the shop floor level. Because process information is often viewed from many different contexts, clear and unambiguous definition of the concepts inherent to process is essential to ensure correct and complete representation and communication. For this reason, the PSL is built upon a formal ontology, with all definitions of concepts captured in first-order logic, specifically the Knowledge Interchange Format (KIF). This logic-based approach not only allows for the unambiguous capture of the meaning of concepts within the representation, it also provides a computer-interpretable form that allows computer programs to deduce new information using tools such as inference engines.

The PSL aligns well with the other manufacturing-process-interoperability standards discussed in this plan. Specifically, PSL is addressing the development of a Process model for enterprise engineering, is exploring issues pertaining to the Development and application of partial-process models, and is geared to issues pertaining to Model storage, representation, exchange, translation, and unification. In SC5 N603, the NP for Manufacturing-software-capability profiling, the key issues were common understanding, context, and taxonomy. The PSL addresses this concern by providing an ontology (taxonomy) of process-related terms and concepts along with formal definition of what these concepts mean. Through these formal definitions, context is made explicit, which therefore assists in the common understanding of concepts among people that view the information in different contexts.

Current work on PSL has focused on the development of the formal ontology that will underlie this language. Research to develop the syntax and grammar of the language has not yet begun but is expected to begin shortly. Therefore, as the work stands now, PSL is more of a data model (ontology) than a language, but is expected to grow into a language in the near future.

The part of PSL that is ready to be standardized now is the PSL ontology; that is, such concepts as the resource roles and activity duration. Some research and development is needed before the language specification is ready for standardization. These are, for example, the exchange syntax and grammar. Another part is the semantic mapping to other languages such as XML, UML, and EXPRESS. Except for the EXPRESS mapping, development is needed for this part also. Conformance and compliance requirements will be a part of each standard.

The PSL standards will probably have a compliance theme. That is, the standards will prescribe what is necessary for an application or implementation to be PSL compliant. Pursuant to the compliance theme, the following are categories of possible standardization:

• Formal definitions of the terminology of each application--requirements for software
• A standard set of definitions or ontology--this is the PSL core and extensions
• Definition of kinds of statements in the metadata--the PSL syntax
• Criteria for compliance--degrees of compliance based on levels of capability, mapping rules, and acceptable methods for creating them.
• Some type of mediation facility, either automatic or not, that would establish the level of compliance for each transaction