3 DRAFT
03/23/98
CHAPTER ENGINEERING PRODUCT AND PROCESS DESCRIPTION
The "Islands of Automation" in the product development process are increasing
in volume at an alarming rate. There is a tendency to address these islands as a basic problem and to focus attention on the hardware/software network architecture on which these islands are built. It is now becoming clear that the information generated and transmitted is the real investments of the islands of automation and this information is the real product of the automated system itself. In fact, without the information to be stored, retrieved, used, sorted, manipulated and transferred, the automated system has no purpose. Therefore, in the design/build/maintenance
lifecycle process one must address the "information product" of the automated lifecycle system, in the same manner that one addresses the "manufacturing product" of the development lifecycle system.
3.1 REQUIREMENTS
FOR
ENGINEERING
PRODUCT
AND
PROCESS DESCRIPTION
In the development of complex engineering products such as automobiles, aircraft, ships, computers and weapons, there are many new requirements for describing the product and process such as * 100% Digital Product/Process Definition * Single Source/Entry of Data * Sharing of Data * Integrated Customer/Supplier Networks with 24 Hours World Wide Access * Electronic Ordering, Billing and Payment * Design to Cost Efforts * Quality Improvement Programs * Teaming and Partnerships * Use of Integrated Design/Build Teams
EDM 3-1
DRAFT
03/23/98
Each of these bring a unique set of detailed requirements. The computing industry is attempting to address these needs with enabling technologies and new techniques/methods such as * Data and Process Modeling Techniques and Methods * Information Exchange Standards * CASE Methods and Tools * Object Oriented and Knowledge Based Products Each of these new technologies add to an already growing base of islands of automation. At the same time industry is overtly or inadvertently making dramatic
investment in its technical information. Without an understanding and analysis of the information requirements and the establishment of an integrated approach to
addressing the entire scope to these needs, one will only move from one automation island to the next by creating new languages and more deposits of information. Each introduction of a new technology brings about an investment decision on the part of industry. The key decision is whether or when to re-tool the information factory? At the same time this information must be maintained until the product is no longer in service. During the in-service life of the product, one must have access to the information to provide service to customers and to protect the assets of the corporation for audits and warranties. In many cases, the life span of the information goes well beyond the life span of the software, hardware and network tools used in its initial creation. One must also understand how to manage the introduction of new development technology while protecting the integrity, usability and maintainability of the existing information base. A key to these issues is the description of the engineering process and product; some facets of understanding this process and product description are 1. Understanding the Information Requirements * * * * * Who needs the information? How is it used? Where is it created and where is it used? When is it needed? How long must it be available?
2. Configuration Management EDM 3-2
DRAFT *
03/23/98
Maintaining the configuration and relationship of all the information used to
analyze, define, build, and administer a product. * Managing the configuration of data and process models used within the
design/build/maintenance lifecycle, some of which are typically not under the control of the manufacturing process. 3. Integration of Information to Support all Design Disciplines. * Establishing systems to allow the integration of detailing designs into
subassemblies and major assemblies. * products. * Supporting the use of design information generated for one discipline by Supporting the establishment of electronic mock-ups of large manufacturing
another discipline. One concurrent engineering need exists for tool is Quality Function Deployment (QFD); but a illustrates the current
a generic modeler for QFD. Figure 3.1
communications of the many islands of automation exchanging data. There is a high probability that these data elements have different structures and formats because they likely have been created or changed at different phases of the product creation. Figure 3.2 illustrates a data sharing environment with a central "Integrated Data
Management" function. This function manages and controls the integrity of the data elements and assure that all design functions have consistent data elements. Figure 3.3 illustrates the communications and data sharing environment of the aerospace industry (typical of the USAF ATF program) with three contractors, the USAF System Program Office (SPO) and subcontractors. In this environment there is data sharing These charts illustrate the key role that data plays in
within nodes and between nodes.
the engineering product description process.
3.2
The
NEEDED INFORMATION TECHNOLOGY CAPABILITIES
automation technologies now permit significant concurrency of engineering the
and manufacturing through the sharing of data as both the product design and development process are being created. Facilitating data sharing
requires
standardized product definition models, manufacturing process models, and support process models. The concept of an "Integrated Product Database" requires that these EDM 3-3
DRAFT
03/23/98
product and process models and the associated data elements be defined and shared as a common data. The DoD CALS (Computer-Aided Acquisition and Logistics Support) strategy is moving toward requiring an Integrated Product Database for future weapon systems . The engineering product and process description area has many needed capabilities in information technology. These can be categorized in terms of product modeling, process modeling, data management and control of product and process modeling, knowledge engineering and acquisition and data communication. The following
subsections provide a brief outline of current and needed capabilities in these areas.
3.2.1
Product Model (PDES) is an emerging standard
The Product Data Exchange Specification
for the representation of product data. One of the major areas of focus is on the representation of mechanical parts and assemblies. One way to view the product
definition is a solid (b-rep) based representation of all the information that would normally appear on a part drawing. This includes such information as geometry, While current draft proposal for PDES
topology, form features and tolerances.
contains information models for these topical areas, they are by no means complete. Further direction for PDES include the development of the specification to cover a much broader array of applications and the development of sophisticated
representation of applications and the development of sophisticated representation of PDES using object oriented or knowledge based representations. For the continued
development and evolution of PDES, the group felt research contributions are needed in such areas as the following. Solids Modeling. Current b-reps have limited geometric curves and surfaces but Non-Uniform
provide topological constructs to further organization of representations.
Rational B-Splines (NURBS) linked with surface modeling techniques can represent more complicated surfaces but often lack the topological information available in breps. Integration of these modeling capabilities needs to explored. Non-Manifold
Topology (NMT) has the capability of allowing a uniform representation for wire frame, surfaces and solids. NMT could be a very useful tool for representing some tolerance information such as datum plans, centerlines, etc. EDM 3-4 It could also be useful
DRAFT for representing conceptual design information.
03/23/98
Current NMT modelers have been
developed for polygonal representatives but need to be extended to general b-rep or sculptured surfaces. A tolerance model integrated with the solid is still a topic for
active research (NSF recently held a workshop to address this area). Also needed are solid modeling tools for manufacturing support in such areas such as N/C code
generation, fixturing, and assemblies. Capture of Design Intent. The PDES activities also indicate (at least for mechanical parts) that capturing the decision and assumptions made during design is just as much a part of the product representation as is the final geometry. Research is needed on ways to incorporate such information into the product design process. Implementation of PDES. Much of the early work for PDES focuses on active and passive file levels. Object and knowledge based implementations appear desirable,
but these new technologies have not yet been demonstrated as feasible. Prototype implementation testing of these and related concepts would be highly beneficial.
3.2.2 Process Model The process of information engineering is complex and requires not only a clear understanding of the "as-is" enterprise but also the needs which must be satisfied by the "to-be" enterprise. When putting together an information systems architecture the available computer systems, operating systems, DBMSs, and telecommunications networks must be defined in a technology The architecture. functions and structure of the organization determine the application architecture, along with the data and interfaces. Finally, the information engineering product must be costed, prioritized and scheduled. There are a number of CASE tools emerging to support the process of information engineering. Through a series of CASE tool diagrams, the application
context, functional decomposition, data flow, entity relationships and actions are defined. From this information a data model is built to serve as the basis for data sharing based on a common data structure. The data dictionary/directory is the foundation of a successful data model. The management of data and control requires precise definition of each data element. The National Institute for Standards and Technology (NIST) has prepared a data dictionary specification denoted Information Resource Dictionary Specification (IRDS) which has EDM 3-5
DRAFT
03/23/98
been published as a standard for comment and completion. It can be extended to further definition and could be the foundation for development of future data dictionaries. A Request for Information issued by General Dynamics in 1988 to potential suppliers for an "active" data dictionary/directory received an inadequate response and
indicated the commercial market has not yet provided adequate products in this area. These events indicate there is good potential for full data dictionary/directory capability if the right combination of research and technological capabilities can be
brought together. In addition, an Air Force Integrated Design System (IDS) project workshop on data dictionaries in December 1988 pointed to a need for more
concentrated efforts and research on technical data dictionaries and directories. These activities provide a foundation for needed developments in data dictionary technology.
3.2.3 Data Management and Control of Model and Process Models The transition to a "paperless" data exchange process will require the establishment of electronic data management and control functions and capabilities. The business of buying and selling information must be defined and specified in contracts with schedules, terms and conditions. Many problems must be dealt with as illustrated by
the following questions. When is the data in an Integrated Product Data Base considered final? How is the data validated as meeting the requirements? How is the
configuration management of the product and the associated data accomplished? How is the data protected from unauthorized access and/or change? What are the limits of liability for shared data and how are they defined and implemented? In the past nondigital world, these issues were handled by an infrastructure of organizations including:
engineering, material, contracts, finance, legal, product support, and master scheduling. These organizations or some new functions, such as Information Resource Management, will need to develop the procedures and capabilities for electronic data management and control especially tailored to support the development of engineering products.
Research in this area requires participation of many of the disciplines described above and could be carried out across a university or research institute involving
participation from the above organizations.
EDM 3-6
DRAFT 3.2.4 The Knowledge Engineering/Acquisition graying of
03/23/98
the American work force, especially in the critical areas of
design and engineering, will effectively eliminate much of the knowledge base that these people have developed over their work lifetime. It is imperative that this collective memory be effectively captured, saved and disseminated to the next generation in an expedient manner. This will help assure continuity in the advancement of technology
and minimize reinventions of known concepts. Research is needed on methods to capture, store and disseminate this knowledge. The capture of an experienced designer's or engineer's expertise is typically the province of the knowledge engineer. This person is often an expert in computer science with limited experience in the nuances of the expert's area. Research is needed on how to effectively glean this knowledge. Methodologies and models are needed which can be used across disciplines, but which are robust enough to take into account their
differences. The model(s) should allow the efficient and effective transfer of information from designers at the end of their careers (in the form of a "memory dump"), as well as from practicing designers so that they can archive their expertise continually. This model and methodology may take the form of a protocol, but should be expandable and modifiable to take into account different levels of knowledge domains and areas. The information should be sorted in a format that will allow its retrieval at a latter date by various access machines. This will ensure that the corporate memory will not be lost due to hardware problems. As a result, a robust model needs to be developed which captures the information needed to fully describe an expert's knowledge in a form that will be effectively and efficiently accessed. The model should be expandable to take
into account the different sized knowledge domains as well as the different areas of expertise. As models and methodologies for knowledge acquisition and storage are developed they should be tested in the realistic engineering applications. For example, tests should attempt to capture design information from expert design engineers. After capture and storage, the information should be used by other engineers to produce designs, which should then be checked by the experts from whom the knowledge was obtained. Furthermore testing should be performed in...