5.5 Enterprise Integration
The Enterprise Integration Thrust Area provides a framework for interactive communication of digital product and process definitions in a distributed, heterogeneous, opsystems en-vironment, and is applying electronic commerce technologies to promote agility in manufac-turing business systems.
The goal of this Thrust Area is to provide a robust architecture and tools for seamless inte-gration of all manufacturing enterprise operations, enabling U.S. manufacturers and defense manufacturing organizations to maximize the benefits of advances in agile manufacturing. The integration technologies being developed within TEAM support an agile environment in which many of today’s data sharing problems are solved. The Enterprise Integration Thrust Area is developing the integration architecture needed to ensure that manufacturing data can be com-municated seamlessly, accurately, and securely within the virtual enterprise to support opti-mized manufacturing processes. It is also providing the mechanisms and protocols for access to the TEAM information repositories distributed among the TEAM Technology Centers (the gov-ernment and industry facilities hosting the program technology development and demonstra-tion activities). This Thrust Area team is also working to provide electronic commerce (EC) mechanisms enabling business agility in support of manufacturing operations.
5.5.1 Situation Assessment
A fundamental requirement of agility is that information flow seamlessly from one applica-tion to another. Agile enterprises must integrate informaapplica-tion among engineering, manufactur-ing, and business functions, and this is currently a costly, error-prone, and time-consuming process. Virtual manufacturing enterprises, or “factories without walls,” will never be realized if the data sharing problems that plague American industry are not solved.
U.S. industry currently relies on a tremendous variety of computer-aided design, manufac-turing, and engineering (CAD/CAM/CAE) systems to support product development and manufacturing. Typically, each system uses its own proprietary data structure to perform functions that contribute to the overall design and manufacturing process. When data must be transferred from one tool to another, accuracy and completeness of exchange can be seriously degraded.
Several mechanisms are used with limited success to overcome data transfer difficulties. While some techniques are effective in specific situations, none promote enterprise agility:
• Initial Graphics Exchange Specification (IGES) and direct translators
• Vendor integrated systems
• Contractual requirements
• Manual regeneration or re-entry of data.
Successful IGES translations are possible, but only if special attention is paid to developing data in the sending tool with regard to the characteristics of the receiving tool. This class of translation problems, called pair-wise agreements, arises because:
• Computer-aided tool vendors generally provide a more robust translation mechanism for receiving, rather than sending data
• The IGES standard is sometimes ambiguous, permitting several transfer mechanisms for the same data entity, thus complicating data transfer.
Direct translators can also be applied between computer-aided tools, although they suffer many of the same data ambiguity problems as IGES translators. In addition, many direct translators are built by reverse engineering a tool’s internal data structure without an agree-ment with the tool’s vendor. This introduces software configuration problems and prevents agility.
Some computer-aided tool vendors supply integrated tools based on large data structures, and some attempt to provide an integrated solution for every computer-aided problem that a client may encounter. If a manufacturer can align itself with one of these vendors, it can share data among many applications. However, this solution does not address data sharing among the manufacturer’s customers and suppliers – nor does it address any other tools used by the manufacturer.
Electronic data translation problems can be mitigated via contractual requirements. Some manufacturers require suppliers to provide data in specific formats, placing the burden of translation on the supplier. This forces some suppliers, particularly larger ones, to maintain many types of computer-aided systems, one for each major customer. The economics of such a situation preclude many small suppliers from competing. Therefore, this kind of solution is unacceptable to the agile enterprise.
If translation mechanisms do not work, the only recourse for the user is to re-enter the data from scratch into the desired tool. This is costly, especially when a number of data files are i n-volved, and certainly does not facilitate agility.
A new, emerging standard, Standard for the Exchange of Product Model Data (STEP), holds promise for solving these problems and is being evaluated as part of the TEAM technology demonstration activities. In addition to a greatly expanded data model, STEP should solve many of the ambiguous situations encountered by IGES translators.
5.5.2 Objectives
The requirements for the Enterprise Integration Thrust Area team have been gleaned from a variety of sources including federal agencies, industry consortia, and academic organizations as well as the U.S. industry members who participated in the TEAM requirements definition proc-ess. Based on information from these sources, the key challenges addressed by this Thrust Area are as follows:
• Deploy technologies for effective communication and information management
• Adopt and/or develop an adaptive infrastructure integrating manufacturing and bus i-ness processes
• Demonstrate practices and techniques for technical, business, and cultural agility
• Enable an environment for development and commercialization of integration tools by and for TEAM industrial participants
• Enable electronic commerce applications that support agile manufacturing.
We have developed a challenging list of requirements to realize these objectives. While the list is not all-inclusive, it identifies key requirements for success in enabling agile manufactur-ing within the TEAM program:
• Hardware, network, and software to connect industry and government facilities in an agile enterprise of TEAM Technology Centers
• A Technical Architecture Specification (TAS) to ensure understanding and flowdown of requirements
• Promotion and use of standards relevant to agility
• Documented terminology for manufacturing and business information in the agile en-terprise
• Protection of intellectual property (information security)
• Modular applications that enable “plug and play” use of agile technologies
5.5.3 Approach
TEAM Communications Network
Establishment of an electronic communications network (Figure 5.5-1) is the first step in cr e-ating the virtual enterprise of TEAM Technology Centers and information repositories accessi-ble to all partners. This network, initially deployed in 1995, provides:
• Effective network communications among TEAM participants
• Interactive, collaborative desktop environment for virtual collocation of TEAM members
• An infrastructure that supports enterprise concurrency
• The agility to incorporate new technologies as needed.
TEAM is leveraging existing and emerging networks to field the TEAM Communications Network without performing any new development. To leverage the emerging National In-formation Infrastructure (NII), TEAM is initially using Internet tools to facilitate open comm u-nication among TEAM members.
All TEAM documentation is maintained on servers available to the Internet. WorldWide Web (WWW), one of the most advanced information systems currently deployed on the In-ternet, is used to distribute TEAM electronic documents and make on-line training and educa-tion assets available to all participants. TEAM employs standard document sharing methodolo-gies using Hypertext Markup Language (HTML).
Many interactive concurrent engineering and other manufacturing applications that promote agility exceed currently available Internet bandwidth. Virtual collocation, or the “instant
meeting,” and multimedia shop-floor control work instructions are typical examples. To pro-vide this level of capability, we will use the Advanced Manufacturing Technology network (AMTnet) being put in place in a joint initiative between Sandia National Laboratories and in-dustry. Like Internet, AMTnet is built on the seven-layer Open System Interconnection (OSI) networking model and uses standard TCP/IP transport/network protocols.
Internet/AMTnet
• Intersite File Manager • FTP Server
• Web Site
TEAM Database & Repositories
Industry
DOC/NIST DoD
DOE
Figure 5.5-1 . The TEAM Communications Network will provide ready access to TEAM data and facilitate open communication among TEAM participants.
Collaborative desktop requirements stemming from TEAM will likely spur other technology providers to accelerate deployment of faster network technologies and topologies such as frame relay, switched multimegabit data service (SMDS), and asynchronous transfer mode (ATM). Faster network bandwidth will enable TEAM to exploit digital video teleconferencing and dis-tributed object management to demonstrate the benefits of advanced communications tools as enablers of agile, virtual enterprises.
TEAM’s security requirements include authentication, validation, configuration manage-ment, access control, and confidentiality. To satisfy these requirements, several standards are being examined for implementation. One such standard is Open System Foundation/Distrib-uted Computing Environment (OSF/DCE) Security Services, including Kerberos Version 5 for authentication. Others include DCE privilege servers; secure DCE Remote Procedure Calls; and Portable Operating System Interface for Computer Environment (POSIX)-compliant DCE Ac-cess Control Lists (ACLs), login, and Registry Application Programming Interfaces.
The Andrew File System (AFS) is a promising candidate for replacing Sun’s Network File System (NFS) de facto standard, especially with respect to Distributed File System (DFS) secu-rity. AFS improves on NFS by including local disk caching, Kerberos authentication, file system replication, and automatic tracking by file system processes and databases. AFS also establishes ACLs, global naming schemes, and common name spaces for clients. AFS will probably be i m-plemented to provide DFS security for TEAM. These security mechanisms are undergoing a period of rapid evolution and may change substantially during the life of the TEAM program. TEAM Enterprise Integration will monitor and implement changes as required.
To support continued evolution of the TEAM Communications Network, the Enterprise In-tegration team will:
• Expand deployment of secure, shared workspaces, file structures, and servers
• Continue training of TEAM members on network use
• Deploy a low-end, workstation videoconferencing capability for small businesses
• Deploy high-speed digital videoconferencing, as soon as practicable
• Deploy SNL’s Interactive Collaborative Environments (ICE). Technical Data Archive
The Enterprise Integration team is responsible for providing electronic access and archival of TEAM technical data. These activities include siting of TEAM site data repositories; acquisition of hardware for archiving data; and development and population of a data model to support TEAM product vehicle demonstrations.
The Enterprise Integration team will also provide the mechanism to create and deploy a material properties and constitutive model repository to support an agile enterprise. Through-out the years, the DOE National Laboratories and other government and commercial organiz a-tions have experimentally determined the properties of numerous materials, notably metals. These data have been published in a variety of references, some of which contain hypothesized constitutive equations that model the material’s behavior. Industry has identified that elec-tronic access to these data and models is highly desirable. The data required to mechanically model material behavior, especially in high strain-rate situations such as forming, will be ident i-fied, characterized, and placed into an electronic form and shared with industry via the TEAM Communications Network. These data will also be used within the tools deployed by the TEAM project for demonstration projects.
Recognizing that this database will expand and serve as an asset beyond the boundaries and current timeframe of the TEAM program alone, the Enterprise Integration Thrust Area team will work with interested federal agencies and private firms to establish an independent main-tenance and management function.
Technical Architecture Specification (TAS)
Agile enterprises must have the flexibility to adapt quickly to changing environments. Per-haps the ultimate agile response is the ability to unite with other enterprises to form a virtual organization. In any case, information sharing is one key to flexibility. A well-integrated col-lection of computers, networks, databases, information systems, and graphical user interfaces facilitates the flow of accurate information required for effective decisions and timely action. Standardized interfaces, data structures, and object services are paramount for flexibility in the access, delivery, exchange, and sharing of information within any agile enterprise.
TEAM is addressing this industry need through development of a Technical Architecture Specification (TAS) – an organized collection of information technology guidelines, standards, and preferred deployment strategies that serve as a guideline for technology development and implementation. The TAS guides TEAM participants in planning and acquiring information technology; specifying, developing, and facilitating commercialization of advanced information systems; and resolving information and communication issues (Figure 5.5-2). For TEAM, or any agile enterprise, the TAS provides a central reference and architectural guidance for plans and decisions that affect an enterprise’s information technology infrastructure – the total collec-tion of computers, networks, informacollec-tion systems, and related technologies used to manage and process information.
The TAS has two objectives. The first is to provide easily accessible guidance to TEAM par-ticipants and task teams in the form of a well-researched and current map of information tec h-nology standards, preferred products and technologies, and recommended system configura-tion and deployment strategies.
Incrementally Concurrent Product Model
Object Services Rendering
Services
Neutral Markup
Services MetrologyServices
Solids Modeler
Services VariationalServices Persistence
Services Feature
Services ToleranceServices Auto DecompositionServices
Tool Path Generator Services Security Services History Services Configuration Management Services Other Services Objectbase
Figure 5.5-2 . The Technical Architecture Specification serves as a reference for all TEAM data management activities.
The second objective is to provide the technical basis for enterprise-wide information maagement. The objective of this larger process is to establish an information support enviro n-ment capable of meeting the business objectives of an agile company as a whole, while simulta-neously meeting the needs of individual users.
The TAS is maintained as a living document, accessible via the TEAM Communications Network, enabling technologies and standards to be quickly incorporated or removed as needed. Certain implementation and deployment strategies are inherent in the design and structure of the TAS:
• Reliance on low-cost, high-powered, heterogeneous, flexible desktop computing sys-tems
• Reliance on open systems architecture
• Deployment of networks, servers, and other information technology components neces-sary for a highly integrated concurrent environment
• Emphasis on standards for sharing, distributing, and exchanging information.
The TAS contains an information model of how industrial members share information and a description of the data management, network, e-mail, security, data interchange, object services, and output services (collectively called service areas) that can be used by an agile enterprise. The TAS presents a reference model in the form of a matrix relating service areas to “tiers.” Each tier represents a component of the preferred distributed computing configuration for an agile enterprise. The cell intersection between a service area and a tier represents a common information technology reference or decision point.
Many categories of standards are addressed in the TAS. Enterprise Integration team me m-bers collaborate with DoD and DOC initiatives to enhance, refine, and use existing technical ar-chitectures. TEAM technologies must interoperate with such DoD initiatives as the Contractor Integrated Technical Information System (CITIS). The CITIS specification provides for DoD on-line access to a predetermined format of data within a contractor’s information system. Such data includes CAD/CAM data files and other concurrent engineering information in formats consistent with CALS standards. Although the CITIS standard focuses on exchange of stan-dardized information in a loosely coupled environment, and not on the agile data-sharing envi-sioned by TEAM, similar standards are employed so that data can be generated and exchanged among CITIS-compliant contractors.
The CALS organization has recently proposed an Infrastructure Service Architecture (ISA) that should permit the evolution of CITIS from a file-based, document-oriented cataloging sys-tem to a STEP-based, product-oriented environment. This CALS ISA describes an object-oriented service architecture that will enable flexible re-engineering of enterprise processes. The ISA architecture accommodates distributed, heterogeneous systems, providing an infra-structure for object services. The Enterprise Integration team will work closely with the CALS Profile for Enterprise Integration Working Committee to deploy, test, and extend the CALS ISA. Examples of standards referenced within the TAS include:
• International Standards such as ISO 10303 (STEP) and its relevant Application Protocols (APs), ISO 8879 (SGML), and the ISO 9000 Series for corporate and product quality
• Federal Information Processing Standards, such as FIPS-127 (Structured Query Lan-guage), and FIPS-152 (SGML)
• Military Standards such as MIL-STD-1777 (IP Standard), MIL-STD-1778 (TCP Standard), and MIL-STD-1840 (Automated Interchange of Technical Information – this standard references other standards, including IGES, CGM, and CCITT group IV raster)
• Industry standards such as Common Object Request Broker Architecture (CORBA), published by the Object Management Group (OMG). CORBA is an emerging standard
to provide a mechanism to share information through an integrated, logically central-ized, physically distributed heterogeneous computing environment.
Much work still needs to be done on standards relevant to the agile enterprise, especially in the area of non-geometric information exchange. TEAM provides an infrastructure for devel-opment and commercialization of software that manipulates and uses non-geometric product, process, and business information in a standardized environment, especially in the area of SGML/STEP interoperability.
Access to product and process information is facilitated through implementation and testing of emerging standards, especially STEP. TEAM Enterprise Integration personnel will continue to work closely with NIST and the PDES/STEP organization to promote the use and enhance the viability of the STEP standard, and will participate on committees that will clarify, revise, and extend ISO 10303. Enterprise Integration personnel serve as liaison to STEP and other standards-making organizations.
Common Data and Object TEAM Repository and Dictionary
Recognizing that functional units within the agile enterprise must use common terminology when communicating among themselves, the Enterprise Integration team maintains a data re-pository that contains a dictionary of unambiguously defined data elements, objects and meth-ods employed by the enterprise. This repository and electronic dictionary support develop-ment and commercialization of agile software applications.
We will address those functions that currently can interface with the data elements contained in STEP AP 203. To support the development of the TEAM Agile Enterprise model, the Enter-prise Integration team will introduce object-oriented technology (OOT) into the modeling envi-ronment. Over time, the common data repository will evolve into an object-oriented repository encapsulating both the data and the methods used to store, manipulate, query, and retrieve it. We will maintain, extend, and service the repository, and other TEAM Thrust Areas will pro-vide definitions of their information elements for inclusion in the virtual enterprise’s common data repository.
The data repository allows users and programmers to access and modify metadata about i n-formation stored within a database or series of databases. Data attributes maintained by the data dictionary include data names, data definitions, internal and external formats, integrity and security rules, and triggers. While more-capable encyclopedia or repository products have recently become available (providing a data integration capability for Integrated Software En-gineering Environments (ISEE) products, with considerably more support for an expanded base of objects and automated life cycle activities), most of these products do not yet support an open interface to other vendors’ tools.
The ANSI committee X3H4 is working with the European Computer Manufacturers Asso-ciation (ECMA) to develop a standard called the Portable Common Toolkit Environment
(PCTE). This represents a crucial step toward “plug compatibility” among ISEE systems, which is critical to fostering an attractive market for vendors. Major dictionary and ISEE vendors have announced their intent to move rapidly into distributed environments, and it is believed that the ANSI PCTE standard will be upgraded to support this environment. TEAM Enterprise I n-tegration will work with these standards activities to accelerate these technologies so that they can be deployed in the computing framework that supports TEAM. In doing so, any require-ments specific to an agile enterprise will be communicated to the appropriate organization for eventual inclusion in pertinent standards.
CORBA-Compliant STEP Repository
Collaboration based on shared data with common identification is an agile enterprise re-quirement. The infrastructure developed by TEAM must be able to adapt to changing customer demands, and a standards-based approach ensures this requirement is satisfied. Enterprise
In-tegration will promote the evolution from an infrastructure that supports CALS-based e x-change via electronic files to STEP-based information sharing via a distributed object environ-ment (Figure 5.5-3). We are moving as rapidly as practicable toward a distributed object envi-ronment so that all TEAM participants can reap the object-oriented programming benefits of encapsulation, inheritance, reuse, and polymorphism. Our approach to developing the CORBA-compliant STEP repository is illustrated in Figure 5.5-4.
Several assumptions about key technologies are required to envision such an environment:
• Affordable high-speed networking and object broker technology
• Standard object-oriented database management systems and interfaces
• Commercialization of distributed object broker technology
• Establishment of a Universal Identification System
• Acceptance of STEP by the vendor and user community.
TEAM’s computing framework will be realized when objects can be identified, located, and manipulated across the TEAM Communications Network to create the “illusion of locality” that will enable a highly productive software development and demonstration environment. Ob-jects will appear as if they were created within a local application, when in reality they reside transparently on remote machine. Re-engineering of legacy applications will be performed by encapsulating their components in object “wrappers.” Once encapsulated, the legacy applica-tion becomes available as a distributed service that can be transparently invoked anywhere within the Communications Network.
Industry Advanced Applications Customer ODMG/SDAI Interface Suppliers Object Services STEP Repository • Object Oriented • Physically Distributed • Logically Centralized Financial Services CommerceNet
DOE, DoD, NIST
AMTnet/Internet CORBA
Objectbase
Deploy Repository Exchange Deploy Advanced Applications Deploy Advanced Apps - OMG/SDAI Deploy Distributed Repositories Deploy Distributed OM Environment
• Demo feasibility of exchanging product definition • Extend STEP to include TEAM process requirements • Exchange STEP (extended) between TEAM sites • Determine TEAM process requirements
• Create initial STEP application server
• Extend STEP to include parametrics & assemblies • Link advanced applications to server
• Link TEAM design & manufacturing application to server • Link TEAM process planning to applications server
• Establish C++ STEP Repository
• Provide repository independence for advanced applications • Provide OMG interface to C++ STEP repository
• Provide STEP Data Access Interface (SDAI) DFs • Demo OMG-to-SDAI linkage
• Migrate from STEP data exchange to STEP data sharing • Network C++ STEP repository across LAN/WAN • TEAM sites share product data across network
• Provide TEAM object technology requirements to OMG • Implement CORBA-compliant distributed applications • Simplify/standardize level of STEP applications • Provide TEAM Distributed Object Management
environment based on CORBA
• Provide logical I/F to distributed STEP data
Figure 5.5-4 . TEAM will develop a CORBA-compliant STEP repository to support technology demonstration and deployment projects.
CORBA-compliant object distribution technologies will be deployed in concert with a Uni-versal Identification System (UIS) to locate objects as they migrate between hosts. UIS will fa-cilitate the creation of "persistent" copies of objects. Distributed Object Request Broker (ORB) technology removes address space restrictions, allowing objects to migrate freely between ad-dress spaces and different hosts. This environment will be reached in a series of incremental steps or phases. The first phase provides an environment that facilitates file exchange from a common STEP repository. The ending phase implements a STEP repository that is manipulated by accessing CORBA-compliant objects in a physically distributed, logically centralized co m-puting environment.
The DOE Kansas City Plant is pursuing a technology transfer project with several industrial partners that will demonstrate and deploy many of the distributed object concepts discussed here. TEAM is leveraging this project by participating in this activity.
Other distributed object architectures may gain wide acceptance in the open systems envi-ronment during the life of TEAM. At present, many vendors are flooding the market with ad-vertisements about distributed object technology, but few are delivering tangible products that interoperate across heterogeneous environments. We will continue follow developments in this technology arena.
The Enterprise Integration tasks associated with distributing STEP-based information via CORBA are periodically updated to reflect new distributed object architectures such as Micro-soft’s Object Linking and Embedding (OLE), IBM’s Distributed System Object Model, and NEXT’s Portable Distributed Objects. Each vendor claims its product will maintain CORBA compliance, but that remains to be demonstrated.
Electronic Commerce for Agile Manufacturing
To this point, the discussion and requirements for the Enterprise Integration Thrust Area have centered on the technical aspects of manufacturing, specifically, facilitating the flow of in-formation used to design parts, create models and simulations, plan the manufacturing process, and make products. Procurement, distribution, payment, and licensing are key business proc-esses that support manufacturing, and must be as agile as the manufacturing procproc-esses if com-panies are to realize the benefits of the agile enterprise. It is imperative that an architecture, in-frastructure, and applications be developed that support business agility.
Electronic commerce (EC) is a mechanism that will vastly improve and accelerate business processes. The Enterprise Integration Thrust Area team will provide EC applications (Figure 5.5-5) for agile manufacturing that address the speed, flexibility, and efficiency of the interac-tions between manufacturing trading partners, suppliers, and customers within the virtual en-terprise. External exchange will also be accommodated. The Enterprise Integration team will provide EC mechanisms to procure and deliver (in near real-time) the products and services required by an agile manufacturing enterprise. By implementing paperless exchange of tran s-actions and information in key functions such as procurement, distribution, payment, and li-censing, EC will accelerate the manufacturing process rather than impede it.
The Enterprise Integration team is focusing on the formulation of electronic data interchange (EDI) technology application to reduce costs and time-to-market as part of an agile business strategy. Technology for several manufacturing business areas must be researched, integrated, and deployed, and other systems using EDI examined. Lessons from GATEC (Government Acquisition Through Electronic Commerce), a joint project between LLNL and the Air Force, must be applied. The possibility that the GATEC Value Added Networks (VANs) could be used for TEAM EC is being researched, since several of our industrial participants are Air Force suppliers.
Successful examples of EC can be found today in corporations that have used EDI to solve some business problems. However, today’s EDI implementations have features that are barri-ers to widespread implementation:
• Most EDI transactions are carried over private VANs. Corporations may join existing VANs, but this process is expensive and time-consuming. There is only limited interop-erability between existing VANs, and service providers charge substantial fees.
Customers Suppliers Electronic Data Interchange Payments Checks Other Shipping Bill of Materials Receiving Licensing Services Financial Services • Electronic Billing • Electronic Payment • Electronic Check Imaging
Procurement Services
• Bill of Materials
Distribution
• Shipping • Receiving
Figure 5.5-5 . TEAM will provide EC applications for agile manufacturing that address the speed, flexibility, and efficiency of interactions between manufacturing trading
• Today’s EDI implementations are dominated by large legacy computing systems that do not easily support new applications. These systems require translators to move data to and from the private VANs, and most are designed for batch processing of bulk trans-actions rather than real-time processing of individual transa ctions.
The objective of this task is thus to extend the promise of EC from large corporations to the smallest enterprise, including individual consumers. The Enterprise Integration team is devel-oping an architecture for financial instruments to support EC and demonstrate the viability of this architecture by developing a prototype for an integrated electronic billing and payment system. The prototype will be tested by incorporating it into existing EC projects and networks such as Electronic Commerce of Component Information and CommerceNet. This is a results-oriented project, with a working prototype in the 12- to 18-month timeframe. This goal can be realized using a two-step approach:
• Develop a broad architecture and infrastructure for future EC transactions
• Develop a prototype electronic billing and payment system that validates the architec-ture and delivers a critical EC service.
TEAM Demonstrations
The Enterprise Integration Thrust Area team is responsible for TEAM’s information infra-structure and for the assembly, shipment, coordination, and deployment of these functions and services. Prior to the implementation of high-speed networking among TEAM participants, simulated concurrent environments will continue to be employed as needed to support tech-nology demonstration activities product and TEAM technologies. This Thrust Area provides the necessary equipment and expertise to duplicate the TEAM computing environment at re-mote locations.
