Virtual Manufacturing User Workshop

12-13 July 1994

Dayton Marriott Hotel

Technical Report

Compiled and Edited by

Lawrence Associates Inc.

This report summarizes the issues, conclusions and recommendations generated at the Virtual Manufacturing User Workshop held in Dayton, Ohio on 12-13 July 1994. In addition, it contains the viewgraphs, breakout session reports and selected commentary from participants. The commentary contained in this report does not necessarily represent the views held by the Department of Defense or Lawrence Associates Inc.

Table of Contents

List of Figures

Figure 1-1. VM Vision

Figure 3-1. VM Scope & Integration with Enterprise Functions

Figure 7-1. VM Scope

List of Tables

Table 1. Breakout Sessions

1. Report Summary

Air Force ManTech, in coordination with the Joint Directors of the Laboratories (JDL), launched a Virtual Manufacturing (VM) initiative in order to facilitate realizing VM's potential benefits in defense manufacturing. The VM initiative has become a key component of the JDL's Manufacturing Science and Technology (MS&T) strategy. During the plenary session of VM User Workshop, held on 12-13 July 1994 in Dayton, Ohio, Dr. Kessler of Air Force ManTech described the major elements of the MS&T strategy as (1) a much earlier manufacturing involvement in the product/process development from requirements to design, (2) a focus on process understanding, emphasizing Cp and Cpk (from the 6-Sigma approach), and (3) a lead role in catalyzing government and industry to use best practices in weapon systems design and production, e.g., Lean Aircraft Initiative. The VM initiative is a key component largely due to its potential, significant impact in enabling strategy element number (1).

Over the past year, the VM initiative has generated wide interest and support in government, industry and academia. In addition, many manufacturers have begun implementing facets of VM in order to gain tangible benefits already available. In order to ensure that the needs and directions of those involved in and responsible for defense manufacturing are accommodated in the VM initiative, an invitation to solicit input and broad industry involvement in this new initiative was extended (reproduced in Appendix B).

1.1 What is VM All About

The vision of Virtual Manufacturing is to provide a capability to "Manufacture in the Computer" (see Figure 1-1). In essence, VM will ultimately provide a modeling and simulation environment so powerful that the fabrication/assembly of any product, including the associated manufacturing processes, can be simulated in the computer. This powerful capability would take into account all of the variables in the production environment from shop floor processes to enterprise transactions. In other words, VM will accommodate the visualization of interacting production processes, process planning, scheduling, assembly planning, logistics from the line to the enterprise, and related impacting processes such as accounting, purchasing and management.

Click here for Picture

Figure 1-1. VM Vision

Two events have combined to launch the VM initiative. First, the evolving defense environment and acquisition strategies require development of the capability to prove the manufacturability and affordability of new weapons systems prior to the commitment of large production resources. In some cases, the production resources may never materialize, but provision for subsequent production must be possible should the requirement arise. Furthermore, the "near zero" production paradigm places increased emphasis on methods for maintaining manufacturing proficiency without actually building products. "Manufacturing in the Computer" has the potential of redressing these issues. Second, the last decade has witnessed tremendous advances in modeling and simulation technologies affording a realistic opportunity to build such a computing capability. For example, the Distributed Interactive Simulation (DIS) program has demonstrated the usefulness of Modeling and Simulation (M&S) in an environment rivaling manufacturing in complexity.

Prior to the workshop, VM was defined simply as an integrated, synthetic Manufacturing environment exercised to enhance all levels of decision and control. This short definition attempted to capture the notion of "Manufacturing in the Computer" in a rigorous manner, and simultaneously encompass its various applications from the shop floor across the enterprise. However, as indicated in much of the commentary, a single definition of VM probably cannot suffice.

Three overarching paradigms emerged during the workshop. For each of these paradigms, a definition of VM is proposed to capture the view of VM within that paradigm. For each of these definitions, the term "Manufacturing" should be construed in a broad sense to include not only production, but also suppliers, customers, and other processes that impact production (This broad sense is often referred to as "big-M").

¨ Design-Centered VM: VM adds Manufacturing information to the IPPD process with the intent of allowing simulation of many Manufacturing alternatives and the creation of many "soft" prototypes by "Manufacturing in the Computer."

à A near-term definition: VM is the use of manufacturing-based simulations to optimize the design of product and processes for a specific manufacturing goal such as: design for assembly; quality; lean operations; and/or flexibility.

à A longer-term definition: VM is the use of simulations of processes to evaluate many production scenarios at many levels of fidelity and scope to inform design and production decisions. An advanced example would be "Combat Customer Empowerment."[1]

¨ Production-Centered VM: VM adds simulation capability to manufacturing process models with the purpose of allowing inexpensive, fast evaluation of many processing alternatives.

à A near-term definition: VM is the production-based converse of IPPD which optimizes manufacturing processes, potentially down to the physics level. An example would be evolutionary re-engineering/optimization of a fabrication facility.

à A longer-term definition: VM adds analytical production simulation to other integration and analysis technologies to allow high confidence validation of new processes and paradigms. Examples would include revolutionary re-engineering of a processes or factory, and/or introduction of virtual corporation paradigms.

¨ Control-Centered VM: VM is the addition of simulation to control models and actual processes, allowing for seamless simulation for optimization during the actual production cycle.

à In general, the workshop participants did not consider a "control-centered" use of VM a high priority; for some, such use was opposed.

In summary, Design-centered VM provides Manufacturing information to the designer during the design phase. Production-centered VM uses simulation during production planning to optimize lines/factories, including the evaluation of processing alternatives (one would expect to do this sort of trade during IPPD, however, the evaluation during this phase has more to do with equipment and people availability). Control-centered VM uses machine control models in simulations, the goal of which is process optimization during actual production. Production-centered VM may or may not use actual control models for the simulation. Using them is desirable, however, this may not be possible because the models were not designed for simulation purposes or because they may simply be code without the knowledge/information necessary for simulation. In one sense, production-centered VM will "control" the factory because the factory will "operate" according to the plan created with the assistance of VM.

1.2 What Benefits Does VM Promise

Virtual Manufacturing is one of the key technologies which allows us to go beyond the assumptions driving the historic acquisition strategies. It provides four fundamental changes for defense manufacturing: (1) VM can be used to prove the production scenarios, resulting in "pre-production hardened systems" (i.e. systems which are developed and verified but never actually undergo actual production runs); (2) VM can support the generation of more reliable estimates of production costs and schedule because the models are based on actual processes, not just parametrics; (3) modeling and simulation (M&S) can significantly improve production flexibility, hence, reducing the "fixed costs"; and (4) reliable predictions of costs, risk and schedule can substantially improve the decision making process of acquisition managers.

As a result of these changes to defense manufacturing, VM will contribute to realizing the following benefits:

· AFFORDABILITY -- Reliable cost and process capability information that can impact key design and management decisions, and support balancing weapon system performance with manufacturing cost, schedule and risk.

· QUALITY -- More producible designs moving to the shop floor and higher quality work instructions to support production.

· PRODUCIBILITY -- First article production that is trouble-free, high quality, involves no reworks, and meets requirements. Optimize the design of the manufacturing system in coordination with the product design.

· FLEXIBILITY -- The ability to execute product changeovers rapidly, to mix production of different products, and to return to producing previously shelved products

· SHORTER CYCLE TIMES -- Increased effectiveness of the IPPD process and the ability to go directly into production without false starts.

· RESPONSIVENESS -- The ability to respond to customer "what-ifs" about the impact of various funding profiles and delivery schedule with improved accuracy (credibility) and timeliness.

CUSTOMER RELATIONS -- Improved relations through the increased participation of the customer in the IPPD process, lower costs, better schedule performance, improved quality, and greater responsiveness.

1.3 What Are the Key Barriers

VM can and must be brought into existence a step at a time. It must be an incremental solution. Adopting VM might require a strategic decision.
A key portion of bringing it into existence is to develop and quantify VM benefits as a part of the process. In so doing, these should be relate-able to currently used metrics (i.e., the metrics will not be revolutionary). They should show a way to relate VM benefits to specific product or system objectives as VM is simply a tool to achieve other objectives. The general process for metric development will follow that of VM in that benefits must be demonstrated, validated and recalculated in the new environment.
Significantly improved cost estimating and collecting systems will be required to be able to deal with realistic cost comparisons at a detail and accuracy level that most current systems cannot support. VM may necessitate adopting radically different accounting practices from those in standard use today.
Weapon system development program funding profiles must change to become more "front loaded" if significant VM is to be performed prior to production or prototyping. Weapon system development on a "pay-as-you-go" basis rather than development cost-shared by the contractor hoping to "get well" in production is essential..
Broader government access and visibility into sensitive company areas could lead to the release of competition sensitive information.

1.4 What Must be Done to Realize VM

Section 7 lists numerous recommendations for implementing/operationalizing VM. The key recommendations are summarized here.

Conduct one or more technical workshops: The technical workshops should tackle their work in the context of the different views of VM (Design-centered, Production-Centered, Control-Centered). Specific issues recommended to be address are listed in section 7.3.
Perform a Background Investigation: what is the status of the relevant technologies, what is going on in research related to VM and associated technologies, where are the gaps in the research and technologies, where is the effort being done, what are the time-frame expectations for delivering the research and technologies.
Avoid Duplication: what is going on already in both industry and government, who is doing this work, what are the schedules and expected results, what are the collaboration opportunities.
Create a Consortium: Because of the long-term, incrementally developed nature of VM, provision should be made for continuing collaboration, sharing and perhaps, precompetitive work.
Demonstration Development: A VM for defense manufacturing must be constructed with the following characteristics: realistic in today's defense environment, complexity stretches the limits of current technology, clear linkage between the benefits of VM and the demonstration scenario, difficult or impossible to effect by means other than VM, wide scope in terms of the demonstrated weapon (sub)system (e.g., involves both parts fabrication and electronics). A SIMNET-style[2 proof-of-principle demonstration is a good example.]
Focus Technology R&D: Focus technology R&D on the specific needs, barriers, issues associated with applying M&S to manufacturing.
Conduct Pilots: Identify and resolve business/cultural issues via pilot programs.

1.5 Concluding Remarks

There is a groundswell of support within DoD and the Defense Industrial Base for VM. The level of participation in the workshop, the expressed criticality of the needs addressed by VM, and the participants' expressed interest in continuing the pursuit of VM, all indicate the users want to obtain the benefits of VM. A total of 83 individuals participated in this workshop, representing all services and industry. This number well exceeded the planners' expectations. In essence, VM is of major interest to users to help solve problems in current DoD environment.

VM is being actively researched and implemented. In fact, over 50% of the participants responding to the survey indicated that VM is being prototyped or is a major thrust at their organization. However, the workshop issues documented in this report show that significant effort is necessary for the DoD to gain the benefits.

2. Introduction

The purpose of this report is to summarize the issues, conclusions and recommendations generated at the Virtual Manufacturing User Workshop held at the Dayton Marriott in Dayton, Ohio on 12-13 July 1994. It contains the viewgraphs, breakout session reports and selected commentary from participants.

A great deal of workshop commentary was collected and summarized into this document in order to provide the reader a full spectrum of views generated at the workshop. The commentary was primarily collected during the breakout sessions, and the breakout session facilitators were responsible for summarizing and accurately reflecting the views of the participants (see Table 1 for the session topics and facilitator names). As a result, it is important to note that this commentary reflects the views, opinions and beliefs of many of the participants and is not necessarily consistent with the views of Department of Defense, the facilitators, or even the majority of the participants..

Section 2.1 provides background on the origin and processes used to conduct the workshop. Section 3 discusses the VM concept, describes the "going-in" definition and participant comments on that definition, and provides several general views concerning VM. Section 4 describes how VM is expected to be used and who will use it, while Section 5 presents the business issues relative to VM including cultural impacts and metrics. Section 6 provides a brief introduction to the technological issues of VM, from the viewpoint of the users. These technological issues will be more fully explored in VM technology workshops being planned for FY95. Section 7 summarizes the workshop issues relative to the VM. Section 7 lists the workshop recommendations. The Appendices contain (A) a list of acronyms used in this report (B) the workshop agenda and invitation, (C) the list of participants, (D) the plenary session viewgraphs, and (E) the breakout session summary viewgraphs presented at the concluding plenary session.

2.1 About the VM User Workshop

The objective for the workshop was to generate requirements from a user perspective, that is, from the perspective individuals and organizations whose decision making process may be influenced by VM.. Users from government and industry were encouraged to the potential roles for modeling and simulation in manufacturing; identify key technical, cultural and business barriers; and feed this information back to the DoD and industry for planning purposes. One secondary purpose of this workshop was to establish the direction for a series of follow-on technical workshops which will match user requirements generated at this workshop with technical capabilities. The workshops are laying the foundation for the VM initiative.

Dr. Kessler highlighted this objective by challenging the participants to (1) view themselves as the customer of the VM initiative, take a stake, and help the government maximize its investment in VM, (2) establish and prioritize requirements for a solid program, and (3) set a framework for technologies and future weapon systems.

A total of 83 individuals attended the user workshop came, 49 representing industry, 7 from academia and 27 from government. (The List of Participants is provided in Appendix C.) In terms their employment, approximately 40% were involved in research, 29% were in management, 28% were in engineering, and 14% were involved with production.[3 In terms of experience with VM, 11% had little or no prior experience, 39% were investigating VM, 26% had a prototype implementation of VM underway, and 25% viewed VM as a major thrust at their organization.

The workshop was organized around two plenary sessions, six breakout sessions where most of the intense work occurred, and a concluding wrap-up session. The plenary sessions introduced many of the current issues and activities associated with the VM initiative, while the breakout sessions provided a forum for focused group discussion and recommendation development. During the wrap-up session, volunteers from each breakout session presented their conclusions (these are included in Appendix E).

Each breakout session addressed VM from a different perspective. Although the original plans called for six different perspectives, the education and training session was dropped because of limited interest among participants (or, perhaps because the other topics were of higher priority), and the manufacturing production and operations session was split into two groups it was oversubscribed. The session objectives and framing questions are presented in Table 1 below. ]

Table 1. Breakout Sessions

SESSION FRAMING QUESTIONS
1: VM & Manufacturing Production 1. What are the primary goals of VM in Sub-Session 1
Operations Objectives: · Explore the Manufacturing Production Operations? 2. What are Facilitator: Dr. J.
use of VM in production operations · the major benefits of achieving those goals? 3. Brink Presenter: Mr.
Assess the ability of VM to help What are the technology challenges in achieving S. Potts Sub-Session 2
maximize throughput · Identify & rank those goals? 4. What will/should industry do in Facilitator: Dr. R.
needed modeling & simulation achieving those goals? 5. What can/should Thomas Presenter: Mr.
capabilities · Identify current government (DoD) do to help achieve those goals? M. Golden
limitations
2: The Impact of VM on the Business 1. What are or should be the primary current & Facilitator: Mr. B.
Culture Objectives: · Analyze the role potential future impacts of VM on the (defense) Kosmal Presenter: Mr.
of management in an environment where business culture? 2. What are the major benefits B. Kosmal
VM and physical production are of realizing those impacts? 3. What are the
strongly mingled · Assess the cultural technology & policy challenges associated with
barriers to implementation of VM · achieving those impacts? 4. What will/should
Identify change agents that will industry do in achieving those impacts? 5. What
support employing VM can/should government (DoD) do to help achieve
those impacts?
3: Quantifying VM Benefits Objectives: 1. What is the significance of the measurement Facilitator: Dr. W.
· Explore the measurement of benefits systems in making decisions? 2. What are some Henghold Presenter:
of using VM · Identify and rank areas potential examples of metrics that will quantify Mr. J. Custer
where significant improvement is VM benefits? 3. What are the primary issues
needed and how VM will accomplish it associated with developing metrics or approaches
for quantifying VM benefits? 4. What must the
measures show to encourage adoption of VM
technologies? 5. What will/should industry and
government (DoD) do in addressing those technology
and policy challenges/issues?

Table 1. Breakout Sessions (Continued)

SESSION FRAMING QUESTIONS
4: VM in Design Objectives: · Explore 1. What are the primary goals of VM in the Design Facilitator: Mr. G.
areas where VM can be used to reduce process? 2. What are the major benefits of Peisert Presenter: Mr.
risk and cost · Explore areas where VM achieving those goals? 3. What are the technology M. Heller
can be used to improve quality · challenges in achieving those goals? 4. What
Analyze how VM fits in with TQM and will/should industry do in achieving those goals?
IPPD 5. What can/should government (DoD) do to help
achieve those goals?
5: VM in Education Objectives: · 1. What are the primary goals of VM in education? Session Dropped
Analyze the education opportunities of 2. What are the major benefits of achieving those
VM and prioritize them according to goals? 3. What are the technology challenges in
benefits · Assess the utility of VM in achieving those goals? 4. What will/should
preserving manufacturing knowledge industry do in achieving those goals? 5. What
can/should government (DoD) do to help achieve
those goals?
6: The Technology Push Objectives: · 1. What are the primary technology issues & Facilitator: Mr. T.
Identify and rank VM technologies · associated potential benefits of VM: · a. In Goranson Presenter:
Define the extent, nature, and metrics Manufacturing Production Operations · b. Over the Mr. R. Joy
for subsequent technical workshops on whole Manufacturing enterprise · c. During the
VM Design Process (conceptual and detail) · d. Over
the whole acquisition life-cycle · e. In Training
and Education 2. What will/should industry do in
addressing these issues? 3. What can/should
government (DoD) do to help address these
technology issues?

3. What is VM?

A definition of VM was prepared by Air Force ManTech and offered as a strawman to the participants. In most breakout sessions, the proposed definition engendered lively debate and recommended changes. The purpose of this section is to present participant insights into what VM is, how it is different from related concepts, where it will be used, and how it should be scoped.

3.1 VM Definition and Commentary

In order to establish a frame of reference, the following proposed definition of VM was presented in the breakout sessions (Note: not all sessions showed the viewgraph with the detailed explanations of the semantics):

Virtual Manufacturing (VM) is an integrated, synthetic manufacturing environment exercised to enhance all levels of decision and control.

To elucidate the semantics:

synthetic: a mixture of real and simulated objects, activities and processes

environment: supports the construction and use of distributed manufacturing simulations by synergistically providing a collection of analysis tools, simulation tools, implementation tools, control tools, models (product, process and resource), equipment, methodologies and organizational principles (culture)

exercising: constructing and executing specific manufacturing simulations using the environment

enhance: increase the value, accuracy, validity

levels: from product concept to disposal, from the shop floor to the executive suite, from factory equipment to the enterprise and beyond, from material transformation to knowledge transformation

decision: understand the impact of change (visualize, organize, identify alternatives)

control: predictions effect actuality

3.1.1 Commentary on the Proposed Definition

The proposed VM definition caused a lot of discussion in each of the breakout sessions. Many of the issues raised are listed below in order to provide insight into the revised definitions presented in Section 1.1. Before the plenary session began, the participants were asked to (1) define VM in their own words, (2) state the most significant benefit of VM environment, and (3) describe the single hardest problem to be solved to accomplish a VM environment. The breakout session discussions began there.

The definition does not adequately emphasize VM's ability to predict schedule, cost and quality. Furthermore, it does not describe the reliability and accuracy of the predictions made possible by VM.
The definition should limit the scope to processes, and improve the interactions between engineering and manufacturing.
The definition should directly address the affordability issue, and emphasize that it provides an iterative solution. In other words, one will use a VM environment in a series of iterations to achieve affordability, in which each iteration involves reviewing/revising needs and approaches to manufacturing.
While it was considered desirable to attempt to arrive at a general description of VM, it was felt that different definitions were likely needed for different audiences depending on their objectives, their level of familiarity with VM and their technical backgrounds.
The words "synthetic" and "control" seemed to evoke the greatest concern, "synthetic" because it connotes something that is ersatz, of low quality, and "control" because, while VM could support or enhance control, it was unlikely in itself to do any controlling.
Virtual Manufacturing must be defined in ways which link it to specific users' experience bases. (Differentiation is important if you are looking for a separate banner.)
The word "manufacturing" must be taken to have a broad, enterprise-wide meaning "Big- M" because significant activities outside the shop floor would be included in models, data, and simulations.
The definition should somehow show the involvement of suppliers and customers.
The biggest payoff of VM will be in influencing product designers and this should be reflected in the definition.

Virtual Manufacturing must be defined in ways which link it to specific users' experience bases. There will not necessarily be a single definition of VM. This presents a serious problem in determining the benefits. It might be that the community can get to multiple views. However, they must get past the transcendent viewpoint to the operational viewpoint. It is important that VM not be all things to all people. Further, we must find a way to differentiate it from all the panaceas presently in vogue (even after a day and a half, several participants wanted to deal with VM as a philosophy.).

3.2 Commentary on What VM Is or Should Be

Developing a definition of something as complex as VM is often difficult; such a definition can rarely capture everything necessary to fully capture the complexity. As a result, selected commentary is presented below to better capture some of its complexity.

VM focuses on improving manufacturing processes by the employment of a model-based approach which leverages simulation capabilities.
Perhaps the most important near term role for VM is to serve as a vehicle for implementation of IPPD practices with a special focus on cost estimation and control functions.
The fundamental notion of VM is that it is a computer-based, simulated product development environment that enables us to "make it virtually" before we "make it for real". The term "product development" encompasses all of the various activities, both business and technical, associated with developing and producing a given product. However, VM does not simulate all of those activities. For example, VM does not simulate the design process. It supports the design process. VM does not simulate reliability or quality engineering, but in many cases a VM simulation may need access to design, reliability, quality and other kinds of information. Figure 3-1 represents an attempt to capture the idea that while VM is not design or the "...ilities," in order to accomplish the desired cross-functional trade-off analyses, it must in most cases be integrated with all of the relevant enterprise functional areas via a trade-off mechanism (IPPD process).
Click here for Picture

Figure 3-1. VM Scope & Integration with Enterprise Functions

VM allows for the creation of many more "soft prototypes" than currently (by reducing both cost and time factors), and/or reduces the cost of the prototyping process overall.
VM is model-based manufacturing, with tools that leverage those models. Primary among the techniques used is simulation, which can reduce some costs of manufacturing and allow exploration of many options in a mixed real/computed space.
At the local level, VM adds simulation to control processes to allow for expedited re-engineering/improvement of processes.
At a more global level, VM provides for evaluation of partial and complete designs by "manufacturing in computers" in an enhanced IPPD environment.
VM is not a single solution, architecture or monolithic database approach. It is a collection of many smaller, incrementally implementable tools (which leverage modeling and simulation), together with some more overarching concepts which may require larger investments by developers and users.

3.2.1 Why VM Different From ...

As with any recently emerging concept, questions of why it different from some other concepts are always raised. In this section, we have presented excerpts of those differences from commentary at the workshop for well known related concepts.

3.2.1.1 IPPD

As Figure 3-1 suggests, IPPD is a cross-functional trade-off mechanism that enables the flow of relevant information to the design and manufacturing processes. VM simulates the manufacturing/production/assembly process. As such it must in most cases have access to that information, but it is not the mechanism that enables the aggregation and flow of that information.
Concerning IPPD: VM supplements the IPPD process since it provides a pathway for manufacturing knowledge to be migrated to early phases in the life cycle. Its impact can be significant:

¨ It allows the IPPD engineer to work with simulated processes directly, either wholly or in concert with "real" processes.

¨ It allows the IPPD engineer to aggregate processes into an arbitrary level of aggregation to validate/analyze soft prototypes. Often IPPD benefits do not scale through aggregation (several best individual processes do not necessarily mean the combination will be best, or even good).

¨ It allows the "P"'s (process focus rather than product focus) to be reversed so that the process owner can be in control, either re-engineering the product, his/her own process, and/or a process which is somewhere else.

Concerning Concurrent Engineering (CE): VM adds the capabilities noted above. But the sharing infrastructure for VM is more robust than that needed for CE.

3.2.1.2 Modeling & Simulation

VM relies on modeling and simulation (M&S) technology to simulate the manufacturing/ production/assembly process, to enable us to "make it virtually." M&S technology is essential to VM as it is to various analyses, training facilities, entertainment and other applications.
VM is an application of modeling and simulation, but it extends that discipline beyond convention. Traditionally, M&S models things with the intent of simulating. The modeling is for simulation and related analyses only. In VM we are counting on using models that already largely exist, but are not optimized for simulation. Because they are there for other reasons, they are highly dynamic, changing outside of the control of the simulation environment. However, upon occasion someone may want VM to control some elements of the production process.

3.2.1.3 Virtual Corporation

VM adds simulation to the Virtual Enterprise (VE) concept, which complicates the problem greatly. However, the scope is radically reduced because the VE (or Enterprise Integration) capabilities needed are limited to improvements in manufacturing.

3.2.1.4 Virtual Prototyping

Virtual Prototyping often refers to the product, and the prototyping process may be not depend on any of the actual production processes. If the Virtual Prototype (product) were "constructed" using simulations of the planned production processes, then one could say the virtual prototype was created using virtual manufacturing.

4. How VM will be used

The following categorization shows the breadth of areas in which VM might be used.

· CORPORATE MEMORY -- Corporate memory will be enhanced in the near-term through the increased development and use of expert systems to capture the knowledge of subject-matter experts. Over the long-term the impact will be much more significant. While the details of product design are presently captured as part of the corporate memory in a fairly systematic way, manufacturing process details often are not. Using expert systems in conjunction with VM would be a significant improvement by providing process capability and cost information to guide the product design process as well as adding some viability to the concept of "shelf technology" where a product might go into production long after the initial design prototyping and testing are completed.

· CAPITAL INVESTMENT -- Manufacturing models and simulations will and are having some influence on capital decisions currently, but this use is isolated to a few companies and not widespread within those companies. In the longer-term, VM should be widely used in capital investment decisions since it should allow more credible comparisons of investment alternatives and should also provide history on the performance of past investments which is frequently hard to obtain in the current environment.

· SUPPLIER MANAGEMENT -- The current VM impact on suppliers is probably rare and the use of VM by suppliers themselves would probably be limited to the largest companies because of the anticipated large investment required to install VM. The future impact on supplier management, however, is expected to be very significant. Make/buy decisions will be enhanced through easy access to better quality and more detailed information on costs, capacity, process capability and lead-times as part of the make/buy decision process. Cost control would also be enhanced because of the more accurate cost information available about suppliers. Major suppliers will have early involvement in product design and planning through the Integrated Product and Process Design (IPPD) teaming approach that is likely to be an accelerating and long-lasting trend and will interact with VM in that context. Smaller suppliers will probably be positively impacted by getting much better and more stable product requirements information from their customers and the customers should be positively impacted by not having to invest so many resources in having to solve problems with their suppliers.

· PRODUCT DESIGN -- In the near term, available and emerging modeling and simulation will enhance the effectiveness of systems integration in the design process, and as a result, improve the fit of components, minimize interference between subsystems and, and reduce the dependence on hard-mockups. Also in the near term, electronic co-location of IPPD team members will become more practical and widespread. In the longer term, major improvements to the transition from design to production are envisioned because of much stronger and more effective influence of process capacity and manufacturing cost information on the product designer as well as the ability to do many more design iterations prior to committing to hardware. One spin-off result should be in providing materials that come out of VM and the design process to be used in training the manufacturing workforce the computer based models and simulations could be readily adapted to work instructions or training materials.

· COST ESTIMATING -- The move toward VM will necessitate finer-grained, more accurate cost information than can typically be provided by current cost accounting systems (and VM cannot succeed without this kind of information). This will, in turn, accelerate the current trend toward activity-based accounting systems and other accounting system changes that allow detailed and accurate product costing. Some current reliance on "semi-expert" systems for cost estimating were identified, but these were little more than advanced parametric estimating systems. These systems are not very satisfactory and will be abandoned as the industry moves into VM and better data becomes available to support more accurate approaches. Future VM systems will provide accurate cost data throughout the design, development, and production process. Cost estimating systems will become fully integrated with design and manufacturing databases and will have access to detailed process-level design feature related data.

· RISK MANAGEMENT -- In the near term, VM is expected to see only isolated use in risk management because available models and simulations are exercised to identify risk areas for added management attention. In the future, the role of VM could evolve into having a major influence on management identification of risks and the merits of alternative courses of action at all levels of management. It is likely that the interfaces with VM would be different at each level of management or within each function. The net result would be to understand and manage risks better.

· CUSTOMER INTERFACE -- The interest and enthusiasm of the customer for VM could potentially lead to a temptation for companies to exaggerate the use and impact of VM in their dealings with the customer. In spite of this risk, near-term impacts are likely in more effective inclusion of the customer in the IPPD process; the inclusion of some requirements for VM in customer statements of work; and better responses to customer "what-if" questions about changes to budgets and delivery schedules. In the longer term, VM will enhance the credibility of responses to "what-if" queries significantly and this, in turn, will have an important impact on program stability by allowing decisions about program budgets and delivery schedules at all levels of the government to be based on accurate and credible information. The customer's ability to participate in the IPPD process should be greatly improved. Uncertainty remains about what changes might evolve in customer oversight as a result of the enhanced visibility available. The risk that extensive "how to" requirements for VM might be placed on future contracts might suboptimize the effectiveness of VM deployment and use.

· FUNCTIONAL INTERFACES -- VM will potentially accelerate the current trend toward weaker functional distinctions within companies by promoting the widespread sharing of information and enhancing close inter-functional working relationships within the IPPD process. This trend, in the longer term, should lead to weakening of the influence of functional departments within the companies and their customers as information sharing becomes even more widespread and effective, and as work efforts are more likely to be organized on product basis rather than being functionally oriented.

· SHOP FLOOR -- In the near term, shop floor people and concerns should have a greater influence on the design process, and manufacturing approaches that have been modeled and simulated above the shop floor will be brought out on the shop floor to validate the models and simulations. In the longer term, significant improvements to work instructions will be seen through the ready availability of graphics. Much better tooling will be available on the shop floor with features that make it easier for the worker to succeed via access to better instructions and illustrations to promote error-free tool use. This will also make it easier to accommodate the envisioned drop in the average skill and education level of shop-floor workers. The proofing of designs and manufacturing processes in the computer prior to commitment to hardware should sharply reduce the problems on the shop floor. Labor relations issues are anticipated to arise as the character and/or existence of some unionized positions such as process planning is impacted by the evolution of VM.

4.1 Commentary on How VM Will Be Used

It must be recognized from the outset that using VM to support part manufacturing is vastly different from VM to support assembly processes. While these will no doubt be integrated eventually, they will likely be developed and implemented separately.
VM will be used to investigate alternatives, make decisions, and perhaps execute functions.
Given the incremental implementation strategy, individual engineers will be attracted because their tools will allow simulation based analyses to enhance their individual function. This presumes some critical mass of tools and some initial infrastructure capabilities. Each design function (however defined) could be dramatically improved.
A more radical implementation strategy proposes a new class of conceptual or high level designers/managers. These people would look at views (enabled by the simulation and aggregation of processes) that are not currently possible to identify problems and possibilities and use high confidence analytical results to optimize manufacturing processes. Their view could be an arbitrary aggregation of real and simulated processes. Therefore, companies will use this capability to avoid mistakes and save money.
VM introduces a new, much more accurate and verifiable level of manufacturing information to the IPPD process. It expands the design "solution space" because it enables the rapid verification of more designs that incorporate (potentially) more solution principles. (Note: The word "solution principle" refers to a basic approach to solving a design problem. For example, four possible solution principles for an automobile propulsion requirement might include reciprocating engine, rotary engine, turbine engine, and electric motor.) The goal is that VM will expand the design space by enabling designers to reliably and cost-effectively evaluate many more designs via the simulation of multiple manufacturing alternatives and the creation of "soft" prototypes by "manufacturing in computers."
The role of VM in design is to make product development information, including manufacturing process, fabrication, assembly and associated support information, integral to the design process. "Integral to the design process" means that a VM implementation would not merely make the designer aware of product development issues, but would provide a mechanism to reliably and verifiably link end-product or component cost to specific design features and tolerances. Ideally, VM would enable a designer to test the manufacturability of a design (not merely its performance) before going to production.
The goal is that a VM simulation would provide designers with timely and reliable cost and producibility (i.e. process capability, fabrication, tooling & assembly) information as it impacts the features of a given design, OR as cost and process capability requirements are impacted by the features of a given design. That is, process information from VM can influence design parameters, and design parameters can influence process capability requirements. In a VM scenario, this information would be delivered much faster, more accurately (i.e. with less uncertainty) and with much more completeness than is possible today.
Designers naturally focus on the part or product, and consider production. VM provides new opportunities in production systems design by enabling the designer to effectively balance design options with production equipment. For example, adding a new machine might be an overall less costly option than another design option with existing equipment.

4.2 Who Will Use VM?

Users of design-centered VM would be product and process designers at arbitrarily early stages in design with the primary intent of optimizing processes and a secondary intent of affecting the design by design-for-producibility.

¨ Note: Individuals in the design group would probably not want to make the distinction between "primary" and "secondary"...They would say that it is a dual intent, that it cuts both ways...etc.

Users of production-centered VM would be factory managers and engineers, during both design and operation, with the intent of optimizing the factory's processes at an arbitrary level of aggregation or granularity.
In both paradigms, the users could be focused on a finely detailed element of the process, or a high-level, aggregated view of a substantial part of the operation. In both cases, the users could be designing new processes or factories, or re-engineering existing ones. In both cases, simulation allows for enhanced, possibly unique, analyses to inform the process.
VM will eventually be used by a variety of people across the product development and production spectrum. The users (and eventually the sponsors) determine the metrics/benefits. The potential user set and their associated problems are well captured in looking down the diagonal of the VM matrix (shown in Figure 7-1). It is important to note that different users will apply VM to their own problems and in their own ways. There is a direct linkage of the "who definition" back to the VM definition above. For example, if we focus VM on the shop floor and perhaps the control function, then a specific user class emerges. The important point is that there will be multiple classes.

5. Business Issues

5.1 The Benefits of VM

Several key benefits of VM can be cited. Following this list of workshop-identified benefits, the potential for realizing these benefits is listed, categorized as short-term versus long-term.

· AFFORDABILITY -- A dramatic and pervasive benefit is expected to emerge in the area of affordability. Many of the risks and problems that have driven the costs of weapon systems in the past will be positively impacted as reliable cost and process capability information impacts key design and management decisions.

· QUALITY -- Product quality should be greatly enhanced through the more producible nature of the designs that will move to the shop floor and the higher quality of the tools and work instructions available to support production.

· PRODUCIBLE PROTOTYPES -- The very first article produced in hardware should be relatively trouble free if VM realizes its full potential since the manufacturing process and the design will have been modeled and simulated and refined in the computer prior to reaching the shop floor.

· SHORTER CYCLE TIMES -- The development cycle should be substantially shortened through the increased effectiveness of the IPPD process and due to the ability to go directly into production without false starts.

· RESPONSIVENESS -- The ability to respond to the needs of customers for product capability should be significantly enhanced in both cost and timeliness. The ability to respond to customer "what-ifs" about the impact of various funding profiles and delivery schedule should be markedly improved in both accuracy (credibility) and timeliness.

· CUSTOMER RELATIONS -- The benefits cited above coupled with the increased participation of the customer in the IPPD process should result in improved customer relations. Customers will appreciate lower costs, better schedule performance, improved quality, and greater responsiveness.

5.1.1 Potential Near-Term Benefits (<5 years)

Perhaps the most important near term role for VM is to serve as the vehicle for implementation of IPPD practices with a special focus on cost estimation and control functions ("control" in the sense of the production-centered VM).
Improve manufacturability and reduce life-cycle costs for designs that move into production.
Substantially reduce time to market via the elimination of Engineering Change Order's (ECO's), fewer "hard" prototypes, reduced scrap, reduced testing, and elimination of rework (i.e. the "hidden factory"). In the case of many DoD systems, "reduced time to market" translates into "zero schedule slip."
Reveal key strengths, deficiencies and voids in manufacturing processes.

5.1.2 Potential Long-Term Benefits (>5 years)

In considering the goals of VM, the overall objective must be to optimize the design of the manufacturing system as well as the product design from the producibility standpoint. The primary benefit will be reduced cost and increased affordability.
Facilitate first-time quality via process tolerance allocation control.
Facilitate increased quality, manufacturability and significantly reduced acquisition and life-cycle costs for one-pass designs that move into production.

5.2 Culture/Business Policy & Process Issues

There is much evidence to show that manufacturers are committed to effect improvements in their processes. Simulation can be an inexpensive way to enhance analysis and decision processes, and it is supporting a fast-growing modeling and simulation industry. For the near-term, probably the only cultural change needed will be the incremental development, validation and adoption of metrics.

However, workshop participants saw a number business and cultural issues that must be addressed to deploy VM, and offered several culture/business policy and process changes.

The cultural barriers are not specific to VM, instead there are traditional barriers which resist speculative, revolutionary infrastructure change. Recognizing this, VM must be implemented incrementally, with each increment justified on its own.
Significantly improved cost estimating and collecting systems will be required to be able to deal with realistic cost comparisons at a detail and accuracy level that most current systems cannot support.
One must prove that the costs for incremental investment provide incremental benefits which outweigh those costs. The capability to link any additional up front costs to believable down stream benefits is required. This linkage must be in "upper management" (read $) terms.
Because of the current difficulty in quantifying the payoff of VM and the long-term nature of the investment involved, it is anticipated that investments in VM will be difficult to sell to management in some companies and will have to be approached as a strategic investment.
There were undercurrents of how were we going to "prove it" particularly if we are looking for dramatic benefit/change (e.g. elimination of an acquisition phase, significant reduction in physical prototypes, etc.). This ties back to some of the issues with regard to how one would assess changes in corporate procedures and organizations that evidence a relation to VM or its technology pieces.
Weapon system development program funding profiles must change to become more "front loaded" if significant VM is to be performed prior to production or prototyping. Weapon system development on a "pay-as-you-go" basis rather than development cost-shared by the contractor hoping to "get well" in production is essential..
Increased customer visibility into company operations and decision making processes may reduce flexibility.
Implementation of VM could lead to conflicting government requirements . Since the scope and impact of VM is broad, the areas of responsibility of numerous government offices will likely be affected. This could lead to a proliferation of VM-related government requirements or mandates.
Broader government access and visibility into sensitive company areas could lead to the release of competition sensitive information. Hence, policies to protect competition-sensitive information relating to VM must be developed.
The current trend toward more performance-based and less procedural ("how to") type regulations and requirements must accelerate. "How to"-type requirements in VM could become very inefficient and counterproductive.
A government commitment to the gradual, long-term adoption of VM would assure the most rapid and effective adoption. Moving too fast or sending mixed signals may have the opposite effect.
VM implementation must be strategic to the corporation, driven from the top level, because implementing VM will be a major corporate investment and will require coordination with many (if not virtually all) functional areas of an enterprise.
VM can potentially be counterproductive to IPT formation in that it could induce "software isolation" if the software can provide the information about manufacturing, why talk to the manufacturing engineer. "Software isolation" would be dangerous because the software will never be fully adequate. It will remain a tool, not a panacea.
Numerous legal and cultural/mind-set issues must be addressed to establish highly effective partnerships and inter-corporate information exchange.
The design paradigm requires major cultural change if it is taken literally in the long term. Suggestions were:
The design paradigm for VM may require a major reinvention of the DoD acquisition process (a change that may necessitate something like VM to effect). In particular, changing responsibility for design of processes to at least the phase currently populated by product designers.

5.3 Measuring VM

Defining a set of metrics which can adequately describe the incrementally achievable benefits of VM is a critical path item for both development and implementation. While all may be derivable from an underlying set of metrics, the benefits must be reliable, believable and grounded in reality. Additionally, they must be mapped to the terminology and experience base of specific users and sponsors. This mapping will be markedly different depending upon the individual user viewpoint. Examples are as follows:

¨ The unit process/production view can measure benefits in terms of fewer engineering change notices, reduced MRB actions, reduced process variability, etc.

¨ A system level/concept development viewpoint would be much more interested in benefits measured in terms of less time to market, bigger market share, etc.

¨ A system level/concept development and subsystem level/DemVal viewpoint would be interested in benefits measured in terms of "better" design trades.

¨ Viewpoints which take in the entire diagonal of the VM matrix would be interested in such items as better profit margins, and for the defense, the elimination of a life cycle phase. (See the Quantifying VM Benefits breakout session viewgraphs in Appendix E.)

The above are a limited set of a multitude of examples. There are significant issues with any example. The primary issues are:

¨ Attribution of benefits to specific VM applications or implementations may be nearly impossible. This is particularly true when VM is viewed in its broad scope. How do you know you have improved manufacturing through the application of VM during design? How do you track the benefits over extended time frames with multiple factors being involved?

¨ Validation is critical, with the tie to system/ enterprise level tools being a potential Achilles heel. As you traverse the VM matrix from lower right to upper left, you get further from physics and near term feedback of the goodness of decisions. The natural tendency is to look for the high payoff of early VM influence. However, how the results will be validated/proven becomes more and more questionable. You must show the benefits of VM in a non-disputable manner.

¨ Quantification in easily understood terms is paramount. How do you quantify the details of abstract processes such as design? Part of this issue points also to attribution discussed above as related to aggregation/dis-aggregation.

¨ The generation of benefits absolutely demands the existence of baseline data. Industry has not shown a willingness to share baselines.

The known issues associated with metrics need to be organized and clarified in detail and reviewed at the technical workshop.

¨ Defining a set of metrics which can adequately describe the benefits of VM is a critical path item for both development and implementation.

¨ VM will be used only if users are convinced that the potential risk adjusted benefits outweigh the costs.

¨ The users (and eventually the sponsors) determine the metrics/benefits as well as the priorities.

¨ The benefits must be demonstrated and the application risk must be reduced in an evolutionary manner.

¨ VM will be used only if users are convinced that the potential benefits outweigh the costs. In defining the benefits, each user will adjust their potential for his or her feel of the risk. Thus the benefits must be demonstrated and believable.

¨ Metrics that currently exist should be used. The hard part is developing the management science that makes the linkage of traditional "big" metrics (cost, quality, cycle time) to the functions of the new infrastructure. This should be done by empirically validated mathematical linkages, and intuitive "small" metrics. Small metrics for lean (for example) are: percentage of empowered process owners; floor space; distance the part travels; percentage of excess materials. etc.

¨ The benefits for the incremental implementation must use the benefit measures that each component buyer/user employs. Since these are already accepted and linked to the business's metrics, we don't need to develop new metrics and measures.

¨ High confidence, formal methods must be developed which map the simulations to common metrics in the enterprise. Perhaps new metrics may be required; these must still feed the high level metrics of cost, schedule and quality.

6. Technology Issues

One breakout session was devoted to addressing the technologies of VM. The name of that breakout session, Technology Push, was deliberately chosen so that participants would focus on technologies that can or will support user needs, rather than starting with a technology and determine which needs it might solve (the proverbial solution-in-search-of-a-problem). The Design group also contributed significantly to technology issues.

New integration technologies and philosophies are emerging. Visualization hardware and some software is becoming more affordable and widespread. New modeling and model abstraction techniques are appearing.
Specific technologies supporting VM exist today, however, most must be further developed in order to achieve the VM goals (viz. VM support for rapid design validation and input during the design process).

6.1 Technology Needs

More progress is still needed for visualization technologies, including more affordable hardware.
In addition to M&S requirements, considerable work is needed in database/knowledge base technology, shifting the "intelligence" from the application to the data itself. Multi-level, distributed security is also an issue, as is the need for a methodology, protocol and underlying ontology to represent relevant design and product development process information at multiple levels of abstraction.
Development of a formal, structured methodology for design abstraction. The purpose of this methodology would be to enable designers and engineers to discuss, manipulate and represent design concepts in a way that is computer-interpretable so that various software tools could be built that "understand" what kinds of information are relevant in a given design problem or context and deliver that information to a designer or engineer in a timely manner and in the most useful form.
Development of Models and Simulations. Issues include determining what to model (or establishing an approach for doing so), and determining the degree of abstraction and level of depth required. The abstraction and depth issues are related to the design phase (e.g. concept vs. detailed) and the design goal (e.g. the degree to which a design must be manufacturable vs. the degree to which the manufacturing process must be developed to accommodate the design). The flexibility and maintenance of models and simulations is also an issue, as is integration of a simulation with data from all relevant cross-functional areas (e.g. reliability, quality), and business areas (e.g. vendors, sub-contractors). Model and simulation validation is also extremely costly and difficult. In all of these cases, there are business issues which are linked to the technical challenges. The Design Group emphasized that attempting to address these issues without attacking both business and technical dimensions could not succeed.
Development of a design cost database that is useful for estimating the cost impact of various design alternatives even early in the design process. (The Design Group called it an "integrated" database.) Aside from the complex business issues associated with obtaining accurate costing data at a sufficient level of detail, there are two key technical issues. The first issue involves cost modeling with a "big M". What is needed are consistent and reliable ways to relate historical cost information to new designs, getting away from parametric, regression and linear empirical (i.e. $/lb) methods. The second technical issue is the database technology itself. The capability to automatically generate intelligent queries for multiple database systems, each having different structures and query languages, and the ability to aggregate the resultant data, auto-distill it, and present it back to the user, and to do so in a timely manner, is not yet within the reach of current commercial technology.
Human interface technology is needed for complex systems. Sophisticated computer-aided Design (CAD) software today, while improving, still requires a significant learning curve and generally presents to the user a very complex interface. Without improvements in the underlying interface technology, that complexity will be multiplied several-fold when the designer is presented with additional manufacturing and business data relevant to the design process. The primary underlying interface technology of interest here is the ability to distill large amounts of data into a concise form that is presented to the engineer or designer in a relevant and quickly digestible package. For example, a design package might, in the background, query a manufacturing capability database, automatically pair down the response to the items relevant to the current design problem or context, and present the resultant data in a form that is consistent with the design context (e.g. manufacturing process capability for machine tolerance might be fed back to the designer in terms of yield loss as a function of a critical design tolerance).
Multi-level, distributed security. Information security is closely tied to business practices. However, technical issues remain as well, particularly with respect to configuration management during design iterations and the integration of information from across the enterprise into a VM simulation that supports the design process.
Advances in Object oriented dynamic, functional languages (Dylan), and event-based modeling are needed.
3-D surface-based modeling.
Common kernels for model component exchange. For design-centered VM, this would probably be 3-D solids-based, possibly feature-based models; for production-centered VM, this would probably be event-based, possibly network-based.
Portable techniques for mapping metric information from tools to enterprise metrics (cost, time, quality).
Facilities to handle basic needs: configuration management; security; metrics validation and verification.
A general capability to integrate dynamic, distributed, collaborative models without creating a central database or imposing a homogenous solution. This could be called a federating abstraction and aggregation environment. (A longer-term issue.)

6.2 What Are the Technical Barriers?

System speed. System speed includes not only processor and memory access speed, but equally important, multi-channel I/O, combined with network speed and bandwidth. In order to constantly and in something like "real time", (from the designer's perspective), analyze a design as it is evolving, query manufacturing capabilities, run simulations to check design features, as well as access and analyze other kinds of enterprise data, very high speed systems and networks will have to be available for relatively low cost. Networking and systems speeds may have to be on the order of 1,000 to 10,000 times faster than today's high-end workstations and networks.
Machine Intelligence. Fundamental advances in machine intelligence, including machine learning, are needed if we are to enable computers to deal with concepts like design "intent" and design "function" at the abstract levels that human designers typically work. For a machine to really assess design "features" and "understand" their implications for manufacturing, software and systems will have to evolve significantly beyond where we are today. (During a recent documentary on the brain [PBS], it was estimated that the number of transactions that occur in the average human brain in a single minute is greater than the number of transactions that are handled by all of the telephone switching systems in the world in a 24-hour period!)
Process model and simulation validation. A key question is, How can a model (e.g. for product fabrication or of a manufacturing process) that is not simply mathematical or "first principles" physics-based, be validated in the absence of actual data with which to correlate and calibrate the model? Validating the underlying models is one of the most costly and difficult activities in developing a sound simulation. This problem may represent a fundamental technical barrier that could make widespread simulation of limited-duration or low volume processes impractical (i.e., not cost effective).
Interface standards will have to be established in order for many types of equipment, software and databases to be able to work together.
Data deliverable specifications relating to VM will have to be developed for government contracts.
Databases. Universal integratability must be sought so as to bring together (logically) not only the disparate, stand alone information banks within a single enterprise, but also to link eventually primes, subs and customers.
An undercurrent was that technology needs to link the physics view to the cost (presently parameterized) view and how we will go about aggregation. In addition concern was expressed on how to generalize tools to multiple industries and companies within an industry.

6.3 Infrastructure Needs

The Technology Push Breakout group identified three primary components, as above and beyond the normal infrastructure:

There needs to be a common, robust modeling method employed as the normal form of the "master, integrated model." The master model is not a central database, rather a capability to compose information at an arbitrary level of fidelity/granularity. The group believes this normal form is necessarily 3-D surface based, and possibly feature-based.

¨ Associated with this is a common set of semantics, or an ontology, which is used enterprise-wide to ensure that regardless of the tool or domain, the "meaning "of a feature (or other model element) is the same.

¨ Also associated with this model is the capability to assemble a particular edition of the model when needed. This edition will contain information abstracted from many local models which use differing representations and methods. Therefore, an abstracting federation (or federating abstraction) tool is needed. This tool would abstract from diverse models (necessarily including process/control models) to "build" the model needed for the specific view, analysis or tool. The component models would be then be relatively unconstrained and could exist in their peculiar diversity, yet still be distributed, collaborative models.

¨ Note, the group was convinced of the importance of 3-D models in tools, so stressed the 3-D model as the normal form of the infrastructure. But this supposition is not fully supported. Perhaps a normal form more sensitive to event information would be more appropriate.

There needs to be an intelligent browser. This would be a new tool which leveraged the federating abstraction mechanism. It would allow a designer/manager to assemble a model-based view not predefined by any one tool or engineering process. Then an analysis or simulation could be conducted on just those elements, at just that level of abstraction and fidelity. This is envisioned as the basis for a large class of new tools (perhaps advised by expert systems) and new disciplines and capabilities.
This infrastructure introduces a whole new level of issues concerning control of VM itself. Therefore there are a class of configuration management and security (including corporate security) issues which need to be addressed in the design of the infrastructure. The group did not specify these in detail, the presumption being that the problems are obvious and well-defined in the non-VM context.

¨ Probably, all these infrastructure needs are of the high risk, high payoff type; they represent revolutionary rather than evolutionary change; significant investment must be made before significant gains are realized; apparently only government investment can create this technical infrastructure; and the payoff horizon is not near (greater than five years).

¨ The Technology Push group suggested there is possibly a short cut. If DoD (and DoE/DoT/NASA) mandated 3- D surface models in their acquisitions, then the market would be incentivized to create infrastructure. Either way the government pays.

¨ Note that such a requirement is unrealistic and probably not wise even if it were possible. Without a commercial user pull, DoD-specific infrastructure will die. There is another possible shortcut. If there could be found a federating mechanism that allows all tools to retain their models/representations in their native form, then these ponderous infrastructure requirements shrink to near-term achievability. (Reporter's personal interest disclosure here.)

6.4 Tools Needs

The Technology Push group identified five tools areas. The first four of these probably has individual merit without the long-range VM infrastructure and is accomplishable in the near term (less than five years). The first three are tools which require "standards."

A common CAD kernel. The CAD market is slowly building in these kernels but are not converging on a single engine. If there were a common CAD kernel, then CAD models could run in a vendor-independent fashion. (This is related to the attractiveness of 3-d surface models for VM-based simulation.) A CAD kernel deals with images at a higher level of abstraction than IGES/PDES/STEP which focuses on fine-grained detailed composition.
A standard for the communication of visual information. This is probably related to the CAD kernel. Where the kernel focuses on the ease of transfer of the model, this standard (and technology) focuses on its communication. A different representation may be required, together with compression (and possibly security) technologies. Creating of this standard will allow the involvement of several workstations/display devices in a collaborative simulation-based mode. As with the above standard, no one currently owns the problem.
There are a number of common processes, mostly shop floor-related, which have not been explicitly defined, the lack of which would make manufacturing simulation meaningless. Possibly, there is a large class of these processes. An example is material springback when being tooled. This is a common feature, parameter or phenomenon which can be found in many sectors, processes and materials. A model of some type is required for fine-grained physics-based modeling, and it does not make sense for that representation to be constantly redefined.
Possibly this is something to address in concert with STEP and/or NIST funding.
Additionally, there is a tool which seems to depend on the infrastructure, but may not required in a near-term version. This tool would address the "flying carpet" function[4 which VM could make possible. It is such a useful function that evolutionary development would be beneficial. We think there are already several tools which could be used as a baseline which have rudimentary, simulation-based capability to aggregate distributed processes.]

¨ Probably it would make sense to use this as a first program goal since it is incrementally beneficial, has a growing commercial vendor base (and skill set) and has a near-term horizon. Probably, work on this tool could contribute to the longer-term browser and federated abstraction needs.

7. Recommendations

Many recommendations were generated during the workshop. The specific, consensus-developed recommendations from each breakout session, including which organizations should perform what activity, are presented in the viewgraphs contained in Appendix E. The overall workshop recommendations are summarized in the following subsections.

7.1 Scope of the VM Initiative

The potential scope of VM is quite large. What is important is that a time phased, realizable scope for VM be defined. At the moment, VM's scope is so broad that it is not really differentiable from other initiatives or technologies, etc.
The notion that VM cannot be developed incrementally is wrong. That is the way that it is being developed in industry today starting generally from CAD and MRP systems. ManTech's program must be based on a comprehensive understanding of the current VM trends in the aerospace defense industry and should include plans for assisting those near term objectives in addition to supporting longer term goals.
VM is intended to improve the manufacturing process. An enterprise may do this to improve the product toward some goal. Therefore, the scope of the VM products is the (big- M) Manufacturing domain.

Several sessions employed Figure 7-1 in order to help scope the initiative. The horizontal dimension represents the enterprise scope (big-M), while the vertical dimension represents the phase.

Click here for Picture

Figure 7-1. VM Scope

Concerning vertical scope, there is no "early" bound. That is, VM is applied and has effect as early in the design/conceptualization/requirements phase as is possible. The "late" bound is actually before the manufacturing of the item(s), because VM tools are involved up to and including the creating of the process plan. After that point, no "design" tools are involved until there is a process re-engineering function. But at that point, after the process (and/or product!) is redesigned, the process plan is recompiled and VM ceases again to be involved. (This assumes the control-centered VM is excluded.)
Concerning horizontal scope, there probably should to be a continuing shop-floor based center to validate new components and models.

7.2 How to Make VM "Operational"

VM can and must be brought into existence a step at a time. A key portion of bringing it into existence is to develop and quantify VM benefits as a part of the process. In so doing, these should be relate-able to currently used metrics (i.e., the metrics will not be revolutionary). They should show a way to relate VM benefits to specific product or system objectives as VM is simply a tool to achieve other objectives. The general process for metric development will follow that of VM in that benefits must be demonstrated, validated and recalculated in the new environment. Near term, believable payoff is crucial. As a part of the activity, it will be necessary to establish baselines from past efforts. These baselines must come from both companies and procurement agencies and the methods of measurements cannot be foreign to each company's way of measuring itself.

Government, industry and academia should work together to define a VM development roadmap. Once roadmap is developed, some IR&D effort could be redirected towards VM.
Demonstrate the benefit and reduce the application risk. The more grandiose the view of VM, the harder this will be to achieve. One step at a time is the process. There is a definite need to have some near term results which instill confidence in the potential for broad implementation and to build the constituency to attack the larger problem.
Create interfaces with commercial companies to gain access to success stories.
Government should assume the role of facilitator in VM development and implementation rather than dictating VM requirements. Make VM implementation optional rather than a universal requirement. VM should be part of a weapon system program requirement review in the PDR/CDR process rather than be set up for special reviews or contract data requirements.
Provide seed money for pathfinder or pilot projects in conjunction with "real" weapon systems programs.
Seed pilot programs in order to reduce risk. To the extent that the government can help mitigate the high risks associated with a new area like VM, the defense industry will be willing and able to invest in the technology.
Provide incentives for implementation by making costs an allowable charge under the contract.
Accelerate the development and implementation of VM technologies via acquisition policy, motivation with metrics, and contractual requirements.
There seems to be genuine interest by industry in forming a Sematech-like organization to pursue VM-related research and development activities. It would likely be useful to examine the Sematech structure and processes to assess their strengths and weaknesses as a prelude to government action to stimulate such an initiative.
Sponsor/form VM users groups to foster the sharing of information and to guide development of VM.
Create an industry council (include academia) on VM interface standards.
Organize a VM Suppliers Organization as an outcome of a vendors meeting organized by ManTech. Such an organization would seek to find ways to assure that potential buyers have information available on gear that is being sold and on its capabilities. This would overcome a major impediment to the use of existing VM hardware and software, namely, the lack of knowledge of what is available.
A training and education role for VM is clear and special technologies for that role must be defined. This mission could be linked to the capture and retention of vital information relating to design and manufacturing operations as well as to the need to overcome cultural shock barriers to the confident use of VM technologies.

7.3 Conduct a Technical Workshop(s)

As mentioned during the plenary session, one or more technical workshops are being planned to further refine VM issues. The participants at the VM User Workshop were in general agreement that such a workshop or workshops should be held, and many expressed a willingness to participate in those workshops as well. The topics and issues should be addressed at the technical workshops:

Can one of the paradigms (design-centered, production-centered) grow into the other? Which is the more amenable to evolutionary implementation? Which can scale to long-term VM capabilities? Do we need to do both? Shall we pursue design-centered VM, production-centered VM or both?
How Do We Bring the VM Technology into Existence?
Can VM be introduced by evolution? Or does it necessarily require some revolutionary change or a large critical mass of small changes to realize useful benefit?
Re-introduce the education and training issues (see Table 1).
The VM paradigm may depend on re-inventing the skills of engineers, on re-inventing each of their tools which are involved in the process (albeit both accomplished incrementally), and possibly, changing the modeling method across the design enterprise to be feature-based. This may represent a significant barrier to VM adoption. How significant are the changes implied by VM technologies? Can technology address these issues? Is feature-based design a necessary condition for adopting VM?
Clarify the key technical issues (and related R&D strategies):

¨ How do we efficiently, dynamically abstract and aggregate among distributed, collaborative models and data?

¨ How do we deal with configuration management, metrics, and security?

¨ Examine the shortcomings of IGES and other data exchange systems and, working with other agencies such as NIST, organize a program to pursue technologies for as near universal data transfer as can be achieved.

Discuss issues such as VM For Parts Manufacturing, VM For Assembly or VM For Cost Estimation and Control.

7.4 Conduct Background Studies

Two studies should be launched in the near future in order to provide sufficient background for VM direction. The first should define the current VM activities underway in the aerospace defense industry. This should be done in such a way as to assure the anonymity of the firms providing the information. The second investigation should identify the trends in research and development being pursued by other government agencies such as NSF, NIST and DoE.

Conduct a survey of users/customers to get detailed metrics which they would enable them to adopt VM.

7.5 Create an Industry/Government Consortium for VM

Several breakout sessions recommended the formation of consortium for VM. The consortium might be a loosely organized forum for sharing VM technologies, advancements, and activities; or a continuing or long-lived consortium to validate (and possibly develop) VM components, which many referred to as a "Sematech-like" organization.

Based on the studies mentioned in Section 7.4, it should be possible to identify potential members of university/industry/government consortia wherein each group would be based on common VM interests.

7.6 Incrementally Develop VM Capabilities for Specific Production Needs

ManTech should initiate a program to incrementally develop VM capabilities for specific defense industrial base production needs. The Design Group addressed this issue via a set of recommended pilots (see charts in Appendix E).
Participants saw a clear role for VM in their future operations but VM technologies must be developed in an incremental way in response to industry's needs and limitations such as computer `horsepower' and funding.
VM should be implemented incrementally with the increments based on industry trends.

7.7 Create and Conduct VM Demonstrations

Develop and validate VM infrastructure as a development pilot site, technology transfer vehicle, and agent for education/cultural change.

Create a defense manufacturing oriented VM with the following characteristics: realistic in today's defense environment, complexity stretches the limits of current technology, clear linkage between the benefits of VM and the demonstration scenario, difficult or impossible to effect by means other than VM, wide scope in terms of the demonstrated weapon (sub)system (e.g., involves both parts fabrication and electronics). A SIMNET-style proof-of-principle demonstration is a good example.

The demonstration must be substantive, and avoid building just another "Gee Whiz" program with today's current visualization and virtual reality technologies.

Demonstrations should be created to provide quantified, scaleable results and baselines from which to measure progress.

7.8 Reusable VM Models

Reusable VM models are somewhere between patentable items and processes. A patent-like registry service would do for process technologies what the patent office was originally set up to do for product technologies, and would take into account the technological issues involved.

Appendix A. List of Acronyms

3-D modeling 3-Dimensional modeling

ARPA Advanced Research Projects Agency

CAD Computer Aided Design

CE Concurrent Engineering

DemVal Demonstration/Validation

DIS Distributed Interaction Simulation

DoD Department of Defense

DoE Department of Energy

DoT Department of Defense

ECO Engineering Change Order

EMD Engineering Manufacturing Development

IGES Initial Graphics Exchange Specification

IPPD Integrated Product Process Development

IPT Integrated Product Team

JDL Joint Directors of the Laboratories

M&S Modeling and Simulation

MRB Mission Requirements Board

MRP Materials Resource Planning

MS&T Manufacturing Science and Technology

NIST National Institute for Standards and Technology

NSF National Science Foundation

PDES/STEP Product Data Exchange using STEP which is the

Standard for the Exchange of Product Model Data

TQM Total Quality Management

VE Virtual Enterprise

VM Virtual Manufacturing

Appendix B. Workshop Invitation & Agenda

     Times                             Topic                              Speaker         
0800-0830         Registration, Coffee & Danish                                           
0830-1130         Opening Plenary Session                                                 
0830-0835         Welcome                                          Bill Taw (on Leo       
                                                                   Plonsky[[Otilde]]s     
                                                                   behalf)                
0835-0855         Lean/Agile Manufacturing, 2005, & VM             Dr. William Kessler    
0855-0900         Description of workshop goals [[yen]] Agenda     Bill Taw               
                  overview                                                                
0900-0925         New Acquisition Strategies impact on             LTC Benjamin Jubela    
                  Manufacturing [[yen]] What, when, importance     AFMC/ENME              
0925-0950         Industry Experiences, would VM help?             Ray Walker (P&W)       
0950-1010         Coffee Break                                                            
1010-1035         C-17 Experience, Would VM have helped?           LTC John Campbell,     
                                                                   ASC/YCD                
1035-1100         Virtual Manufacturing Initiative [[yen]]         Mickey Hitchcock       
                  Overview: definition, benefits, history                                 
1100-1110         Charge to Breakout sessions                      Mickey Hitchcock       
1115-1215         Breakout Sessions - get acquainted, set agenda                          
1215-1300         Lunch                                                                   
1300-1615         Breakout Sessions (including break at 1430)                             
1615-1700         Afternoon Plenary Session                                               
1615-1700         Simulation Based Design Program                  Gary Jones, ARPA       
1800-1930         No Host Reception                                                       
Day 2                                                                                     
0730-0800         Registration, Coffee & Danish                                           
0800-1015         Breakout sessions                                                       
1015-1030         Break (& preparations)                                                  
1030-1230         Concluding Plenary Session [[yen]] Breakout                             
                  session reports (20 min ea)                                             
1230              Adjourn Workshop                                 Mickey Hitchcock       
1315-1630         Facilitators Wrap-up

Appendix C. List of Participants

Appendix D. Plenary Session Speaker ViewGraphs

Dr. William Kessler, Introductory Remarks and Charge to Participants
LtCol. Benjamin Jubela, Changing Times
Mr. Raymond Walker, Industry Perspective
LtCol. John Campbell, Could Virtual Manufacturing Help/Helped the C-17?
Mr. Michael Hitchcock, The Virtual Manufacturing Initiative
Mr. Gary Jones, Simulation-Based Design

Appendix E. Breakout Session ViewGraphs

VM & Manufacturing Production Operations, Subgroup #1

¨ Facilitator: Dr. J. Brink

¨ Presenter: Mr. S. Potts

VM & Manufacturing Production Operations, Subgroup #2

¨ Dr. R. Thomas

¨ Presenter: Mr. M. Golden

The Impact of VM on the Business Culture

¨ Facilitator & Presenter: Mr. B. Kosmal

Quantifying VM Benefits

¨ Facilitator: Dr. W. Henghold

¨ Presenter: Mr. J. Custer

VM in Design

¨ Facilitator: Mr. G. Peisert

¨ Presenter: Mr. M. Heller

The Technology Push

¨ Facilitator: Mr. T. Goranson

¨ Presenter: Mr. R. Joy