ISO TC 184 SC5 WG1

Organization, Strategies, and Philosophy

James G. Nell

US Department of Commerce

National Institute of Standards and Technology

Manufacturing Engineering Laboratory

Manufacturing Systems Integration Division

Gaithersburg MD 20899 

1998-November

ISO TC 184 SC5 WG1

Organization, Strategies, and Philosophy

James G. Nell, NIST, USA, and Convenor TC184 SC5 WG1, Modeling and Architecture

TC184 SC5 WG1 Organization

TC184 Industrial Automation Systems and Integration has a scope that covers standardization in the field of industrial-automation systems and integration concerning discrete-part manufacturing and encompassing the application of multiple technologies; that is, information systems, machines and equipment, and telecommunications. The exception to that is in electrical and electronic equipment as dealt with by IEC technical committees. In these areas coordination occurs between IEC and ISO, specifically among TC184 and the IEC TC 44, TC 63, TC 3, and TC 93.

TC184 SC5, Architecture, Communications, and Integration Frameworks scope is standardization in the field of architecture and communications including an industrial-automation glossary and the requirements for global-programming-language environments. The chair is Emmanuel G. dela Hostria, US and the secretary is Greg Winchester, US. SC5 has four working groups:

• WG1 Modeling and Architecture
  Convener: James G. Nell, US
  Secretary: Greg Winchester, US
• WG2 Communications and Interconnections
  Convener: Volker von Rhine, DE
  Secretary: Vacant, supported by DE 
• WG3 Industrial Automation Vocabulary (Disbanded)
• TC184 is resolving need for a terminology facility
• WG4 Manufacturing Programming Environment
  Convener: Udo Graefe, CA
• WG5 Open Systems Application Frameworks
  Convener: Graeme Meyer, NZ

TC184 SC5 WG1: Modeling and Architecture

WG1 develops standards that coordinate existing, emerging, and future standards for the representation of enterprises to facilitate computer-integrated manufacturing. WG1 plans to produce standards that relate to information infrastructures, integration frameworks, enterprise models, and enterprise modeling and simulation.

ISO14258, Concepts and rules for enterprise models [1], has just been published by ISO as an International Standard. The standard specifies concepts and rules for computer-understandable models of a manufacturing enterprise to better enable enterprise processes to interoperate. The standard is very careful not to specify standard enterprise processes, standard enterprises, standard organizational structures, or standard enterprise data. In addition, this standard does not specify the enterprise-modeling process, but forms the basis by which enterprise-modeling standards can be developed where they are needed.

ISO 15704, Guidelines for enterprise-reference architectures and methodologies [2], has just completed balloting as a Draft International Standard. The standard defines requirements for enterprise-reference architectures and methodologies, as well as requirements that such architectures and methodologies must satisfy to be considered complete. The scope of these enterprise-reference architectures and methodologies covers those constituents deemed necessary to carry out all types of enterprise creation projects. These architectures also cover any incremental change projects required by the enterprise throughout the entire life of the enterprise, including enterprise creation, major enterprise restructuring efforts, and incremental changes affecting only parts of the enterprise-life cycle.

WG1 is developing a standards-landscape tool to help plan WG1 future projects by defining a logical path of planned standardization from the high-level, or enterprise-level, standards to levels low enough to be in the domain of factory-floor applications. For resources we are using input from industry; the Generalized Enterprise-Reference Architecture and Methodology (GERAM) [3]; ISO TR 10314, Shop Floor, Reference Model for Standardization [4,5]; the CEN M-IT-04, Standardization for Advanced Manufacturing Technologies [6]; and the TC184 and SC5 strategic plans [7,8].

The current versions of ISO 14258, ISO 15704, and their parts, and other relevant documents are posted on a World-Wide-Web site for a persistent reference. Activities of the WG1, such as agendas for upcoming meetings, past meeting minutes, schedules, and planned standardization are also posted on this World-Wide-Web site: http://www.nist.gov/sc5wg1/.

Standardization Strategies

The SC5 Strategy Planning Group is the advisory body to SC5 tasked to define and review the SC5 standards strategy. The SC5 standards strategies assume that SC5 will be the mechanism by which TC184, according to its own strategic plan, will provide an integrating overview across all areas of industrial automation. As such, TC184 will rely upon SC5 as the developer of standards that integrate the standards of the other TC184 SCs, as well as the standards of other relevant bodies. Therefore, the plan makes references to work under the responsibility of TC184 SCs and other bodies.

The plan also assumes that SC5 itself cannot produce all of the standards needed to fulfill the objectives stated in this plan. In some cases, SC5 must rely on other bodies to produce standards that act as catalysts or substitutes for SC5 standards.

The Industrial and Economic Environment in which TC184 SC5 WG1 Operates

Assumptions about conditions expected during the medium term of three to seven years.

• Manufacturing enterprises, due to competition, must continue to deliver increased customer satisfaction and improved quality, with increased efficiency, at lower costs--both of production and ownership--in a shorter lead time

• Customers are moving away from traditional process-oriented standards to an overall performance-related approach to products, which gives businesses some flexibility in determining how the required performance is to be delivered

• Although there is a clear business opportunity for standards that contribute to these objectives, the awareness of users and vendors about existing standards, their status and usefulness and the ongoing work is at a very low level. The level of implementation of existing standards is poor, with very few being widely used and implemented. This in turn leads to a growing base of existing vendor-specific solutions, since the current and future standards will only apply for the next generation of systems

• The increasing use of open standards is already leading to a reduction in resources for formal standardization from the major vendors, impacting both technical activities and the national standards bodies themselves

• The contents and descriptions in standards are very complex and even for most experts in the user industry not understandable. Documentation for guidance and implementation is generally poor, difficult to use or non-existent

• During the medium term of three to seven years, computer and information technologies will continue to change and progress very rapidly

• The new ISO directives will have imposed a tighter schedule for the development of standards. There will be a maximum of three years from new-work-item proposal to International Standard approval and a new-standard proposal shall be very well defined at the start. As is currently the case, the approval of five countries ready to support the work with nominated experts will continue to be essential for any further steps in the standardization work to occur.

Enterprise-Level Trends Expected from the Above Assumptions

• There will be increased use of collaborative structures, involving partnerships that may be created and dissolved rapidly to meet changing market needs.

• The various business functions through the life cycle of a product will be undertaken by increasingly integrated processes. The functions will continue to be optimized to drive down costs and cycle times. For example, the support of complex engineering products will be integrated with the technical definition of the product and the management of its configuration through its life cycle

• Manufacturing equipment will need to be capable of being deployed more flexibly to support manufacture of a variety of products

Technologies and Associated Standards Needed to Support Above Trends

• Business-information requirements that are clearly specified, along with information flows that are optimized, to form the backbone of both internal communication and delivery to the customer

• Elements of manufacturing equipment that are designed for easy integration through local and remote networks

• Modular sets of information-technology tools, used as building blocks that can be assembled into systems with a minimum of integration costs

• Simulation tools to model business processes and operations, and to evaluate the business impact of proposed changes

• Real-time management and maintenance of assets, using multimedia for delivery and presentation of information

Needs from the Standardization Process

In general, the standardization process will need to make more efficient use of its resources, and to work to develop its market in parallel with the standards process. More specifically, the standardization process should provide for:

• Features and functionality that are based on actual and future needs of the users

• Confirmation of industry interest through nomination of experts and/or endorsement of the need for the work

• Funding resources that are managed and directed to match industry priorities

• Cooperation with other standards bodies to avoid duplication and conflict. This would include joint development

• Development work undertaken with careful project planning using small working groups and using phases where first results can be achieved rapidly

• Close cooperation with ongoing research and development work

• Supplementary guidance information for industry, users and vendors, that can be given in an easily readable and understandable short form

• Management of standards to ensure consistency of changes

• Implementers involved from the start of the process and pilot implementations encouraged in parallel with the standardization process

• Monitoring of implementations and addressing of barriers to their progress by standards bodies

TC184 SC 5 WG1 Priorities Regarding Work Items

The priority for WG1 when considering new-work-item proposals will be:

• Standards that enable integration within the manufacturing domain

• Standards that enable integration of the manufacturing domain with other enterprise domains

WG1 will not consider proposals that are not at all concerned with the manufacturing domain.

TC184 SC5 WG1 Work Program and Objectives

Strategic Objective: Enable enterprise agility and extension through architecture, data/information model, physical model, and profile standards for the integration of systems within an enterprise and between enterprises.

Needed Areas of Work to Achieve Objective

• Concepts and rules for enterprise models (International Standard Q3, 1998)

• Requirements for enterprise-reference architectures and methodologies (DIS available Q1, 1999)

• Enterprise-modeling execution and integration services (CEN work occurring; no SC 5 NP submitted)

• Neutral representation of manufacturing ontologies (no NP submitted)

• Management and reconciliation of context-dependent semantics; Alignment of context-driven semantics across enterprise domains (no NP submitted)

• Modeling of sharing and exchange processes in the extended enterprise (no NP submitted)

Strategic Objective: Ensure consistent, integrated standards that can be used by the industrial automation community, including other standards developers.

Needed Areas of Work to Achieve Objective

• SC 5 as technical oversight group for TC 184 (no standards development involved)

• Application program (semantic) repository, involving SC 1, SC 2, and SC 5 WG 4 model alignment (no NP submitted)

• Inter-SC model integration (no NP submitted)

• Develop list of industrial automation standards and reference documents to confirm and verify need for work items and to define their scope (no standards development involved)

• Joint SC experts meeting (no standards development involved)

ISO TC184 SC5 WG1 Philosophy

WG1 has reviewed several enterprise-reference architectures; for example the GERAM [3], developed by the IFAC/IFIP Task Group on enterprise integration, the CIMOSA, developed by the AMICE consortium [9], the PERA, developed by Purdue University [10], and the GRAI-GIM developed by the University of Bordeaux [11]. They have similarities. WG1 feels that the development of architectures and enterprise designs will continue regardless of any attempt to standardize them. In fact standardizing these things may impede the way to integration. WG1 conclusions:

• WG1 is not standardizing an architecture since architectures are best developed for the specific needs of the developer; for example each enterprise will choose its own life-cycle focus and set of processes that it needs. The TC184 SC5 WG1 standard ISO 14258, Concepts and Rules for Enterprise Models, must be a top-level document that provides the concepts that relate to creating enterprise models for all manufacturing enterprises. These architectures should be developed with the ISO 14258 enterprise-model concepts in mind. Then, models developed for use within that architecture will be consistent with models developed for an architecture developed by another group. This way WG1 does not have to rationalize each and every group that decides to create an architecture.

• Given any enterprise-representation architecture, a good set of enterprise models will enable many things: for example, enterprises can make more informed phased investments to improve integration capability, enterprise information will be sharable in both intra-enterprise and inter-enterprise scenarios, enterprise performance can be better predicted, enterprise building and simulation is more consistent, and enterprise operators can have a better and more consistent understanding of complex interactions among processes.

• WG1 recognizes that technology is developing in several areas simultaneously and the specific technology a specific enterprise process will confront on either an intra-enterprise or an inter-enterprise interaction event will change continuously. Therefore the reasonable approach, it seems to WG1, is to provide for and encourage mediating architectures. Process interactions should allow each side to advertise with which technologies and level of technology it is equipped, and let the process software mediate the communication rather that standardize everything in advance. This will encourage development in the vendor community and a use of de-facto standards that may allow developments and interoperability to occur simultaneously.

• The WG1 responsibility in this approach is for our standards to give a guideline structure and rules for the information required on each side of the mediation. This structure is what is envisioned for the document ISO 14258; that is, to present rules, guidelines, and constraints for enterprise models. Each compliant model would contain the same sort of information that the mediation process would need to effect interoperability.

Enterprise-Model Interoperability

Concepts

An enterprise model is information. It consists of structured data and rules about the information that applications use to do their work. An enterprise is large and complex, meaning that many models for many purposes are required to describe what is happening at any one time. Because of the diversity of the applications in an enterprise the information contained in the models is encoded in many formats depending upon the needs of information generators and information users. Models can be in the form of organigrams, spreadsheets, engineering drawings, process-flow data, CAE, CAD, and CAM files. These are the so-called islands of information or automation.

What users want from these models, however, is portability. They want to be able to reuse models across applications and not be dependent on specific application and tool configuration. The solution appears to be unified or integrated models that would provide a single information template for any application. Users want to implement technology that will improve their capability to provide for information from currently differing models to be usable by applications and computing platforms enterprise wide. WG1 feels that a set of standard models would help promote this. The problem to accomplish this is that there are as many different ways of presenting models as there are reasons for wanting to model the domain of interest.

A namespace is a binding space for generically interfacing and managing transactions that covers all platforms, applications, and models. The namespace requires a definition about the manner in which models are interrelated. It also needs to know the state of the models that it will encounter; for example, is the grammar predetermined and constrained, or is it taken as it exists; that is, as it is found in the enterprise(s).

Forms of Interoperability

There are three ways that models can be related to each other; they can be integrated, unified, or federated.

With integrated models there is a standard-model form. Diverse models are interpreted against the common template. Standard or reference models must be as rich as the constituent models. Perhaps all models are stored in standard form and information is filtered or translated by the applications; for example, IRDS Information Resource Dictionary System {12}. Alternatively, constituent model owners can agree to standard models, such as in ISO 10303 (STEP, Standard for the Exchange of Product Model Data). Of course there are enormous difficulties and user resistance associated with standardizing large numbers of models. Therefore, the ability to deal with something less than integrated models most certainly is necessary.

The unified approach assumes that there exists a common meta-level template across constituent models, providing a means for establishing semantic equivalence. The metamodel is not in an executable form as it is in integrated situations. Using the metamodel, any model can be translated into any other. Loss of some semantics is possible. Owners of constituent models establish a normalized semantics. The ISO/IEC JTC1 SUMM, Semantic Unification Metamodel [13], is an example of a unified-model template.

The federated model scenario exists if one assumes that no agent successfully or globally can impose requirements for semantic equivalence across all models of an enterprise. Models must be taken as encountered. The template is at the meta level and, like in the unified situation, the template is not executable. Some degree of integration or unification would help the communication process. Interoperability requires that models be dynamically accommodated rather than having a pre-determined metamodel. This would be furthered with some sort of predetermined terminology system. Federated models in a name space are identified as the most difficult defining problem in process interoperability.

In reality many applications will be dealing with models as encountered, or in the form in use at the time the model was created. This will be quite common in inter-enterprise communications. This occurs when dealing with legacy information. Therefore, in a standard that states rules for enterprise models, where model interoperability is important, the assumption is that the federated situation exists and that the rules presented in the standard, or in related standards, shall be rich enough to accommodate the encountered models, whatever the state.

A standard for enterprise models can enhance interoperability by establishing the elements that must be present in an enterprise model. These elements would come into play when there is need for one process to communicate with another. The querying process would address the responding process. The responding process would present its standard-model elements, which include its capabilities to communicate, to the querying process, whose abilities to communicate are also in standard form. There would be a mediation to find the best fit from among the set of capabilities.

The degree of successful communication then will depend on the skills of the humans observing the process or the quality of the software employed to effect the communication, or both. Therefore, users must analyze and predetermine, if interoperability is to be accomplished, which processes must communicate. Then enterprises must employ procedures and tools so that necessary communication can occur. The more that users wish their process to communicate with processes inside and outside the enterprise, the more pressure there would be to arrange the models in a standard way and to present their process capabilities on the medium on which inter-process communication is exchanged.

Enterprise Reference Architectures and Methodologies

The GERAM framework identifies a set of components that are essential for enterprise engineering and integration. The enterprise-reference architecture identifies the basic concepts to be used in enterprise engineering and integration; for example, enterprise entities, life cycles, and life histories of enterprise entities. GERAM distinguishes between the methodologies for enterprise engineering and the modeling languages which are used by the methodologies to describe and model the structure, content, and behavior of the enterprise entities in question. These languages will enable the modeling business processes and their supporting technologies as well as the roles of the human part in the enterprise operation. The resulting enterprise models represent all or part of the enterprise operations, including its manufacturing or service tasks, its organization and management, and its control and information systems. These models can be used to guide the implementation of the operational system of the enterprise as well as to improve the ability of the enterprise to evaluate operational or organizational alternatives (for example, by simulation), and thereby enhance its current and future performance.

Enterprise-engineering tools that implement methodologies and languages must support enterprise modeling. Ontologies, meta models and glossaries, collectively called generic-enterprise-modeling concepts, define the semantics of the modeling languages. Reusable partial models of human roles, processes, and technologies enhance the modeling process. The operational use of enterprise models is supported by specific modules that provide prefabricated products like human-skill profiles for specific professions, common business procedures (e.g. banking and tax rules), IT infrastructure services, or any other product that can be used as a component in the implementation of the operational system.

Potentially, all proposed reference architectures and methodologies could be characterized in GERAM so that developers of particular architectures could gain from being able to refer to the capabilities of their architectures commonly, without having to rewrite their documents to comply with GERAM. Users of these architectures would benefit from GERAM because the GERAM definitions would allow them to identify what they could (and what they could not) expect from any chosen particular architecture in connection with an enterprise-integration methodology and its proposed supporting components.

References

[1] ISO 14258 Rules and guidelines for enterprise models, ISO TC184/SC5/WG1, 1996

 

[2] ISO 15704 Requirements for Enterprise Reference Architectures and Methodologies, ISO TC184/SC5/WG1 N423, 1998

[3] IFAC/IFIP Task Force, GERAM, Generalized Enterprise Reference Architecture and Methodology, Version 1.6.2, 1998 July

[4] International Organization for Standardization, Reference Model for standardization and methodology for identification of requirements, TR 10314 1, 1990-October.

[5] International Organization for Standardization, Reference Model for standardization and methodology for identification of requirements, TR 10314 2, 1991-June.

[6] Committee for European Standardization, TC310 Strategic Working Group, Standardization for Advanced Manufacturing Technologies, Memorandum M-IT-04, issue 6, parts 1 and 2.

[7] TC184 Advisory Group, ISO TC184 Strategic plan, SC5 N567, 1998-February

[8] SC5 Strategy Planning Group, ISO TC184 SC5 Strategic Plan, SC5 N580, 1998-May

[9] Anonymous, AMICE Consortium, CIMOSA, Architecture Description, ESPRIT Project 5288, Milestone M-2, AD2.0, Vol.2, Document RO443/1 Brussels, Belgium, 1992-August-24

[10] Williams, T.J., The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC, 1992

[11] Doumeingts, G., Vallespir, B., Zanettin, M., and Chen D., GRAI-GIM Integrated Metghodology, A Methodology for Designing CIM Systems, Version 1.0, LAP/GRAI, University of Bordeaux I, 1992-May

[12] IRDS Rapporteur Group, IRDS Framework, ISO/IEC 10027, ISO/IEC JTC1

SC2 WG3, 1990

[13] SUMM, Semantic Unification Meta Model, ISO/IEC JTC1 SC2 WG3, N1360,

1991-Oct-15