Collaborative Prototyping and Product Development on the Web M i s

M
Crriittiiccaall
Miissssiioonn C
EEnntteerrpprriissee SSyysstteem
mss
SSyym
m 22000000
mppoossiiuum
LLeevveerraaggiinngg EEnntteerrpprriissee IInnffoorrm
maattiioonn PPoorrttaallss
Collaborative Prototyping and Product Development on the Web
Jeffrey P. Stavash
Senior Member
Lockheed Martin ATL
(856) 338-4031
[email protected]
John Welsh
Manager
Lockheed Martin ATL
(856) 338-4223
[email protected]
Bipin Chadha
Principal Member
Lockheed Martin ATL
(856) 338-3865
[email protected]
Abstract
Collaborative environments for product development have become the new design paradigm for today’s engineering
organizations. Collaboration permits greater information sharing, concurrent engineering, virtual prototyping and testing,
and total quality management. The results are an increase in product quality and a decrease in lifecycle cost. One key
ingredient missing in collaborations is the ability to capture the dynamic causal relationships between components of the
system being designed. How the components relate to each other is either captured at a very basic level (physical interfaces),
or is left for the designers to understand and keep in mind as the design evolves. The COTS based collaboration
environment has been extended to capture the dynamic causal behavior and is used to develop a tradeoff analysis tool where
designers can evaluate multiple configurations and options to achieve higher quality and cost effective designs.
This paper describes the foundational technologies that are required to implement a virtual team environment for
collaborative product development. It presents the Collaborative Enterprise Environment (CEE) that Lockheed Martin
Advanced Technology Laboratories (ATL) developed for the Air Force Research Laboratories (AFRL). It discusses how
issues of heterogeneous applications, access control, security, and integration across disparate tool sets were resolved to
permit AFRL to collaborate with Lockheed Martin and industry on technology development programs over the complete
lifecycle.
Keywords
Collaborative enterprise environment, dual-use application program, product data management, simulation-based
acquisition, smart enterprise model, system dynamics, virtual team, virtual prototyping.
1 . Introduction
Many of today’s large organizations, such as Lockheed Martin, are relying heavily on collaborative engineering and virtual
prototyping approaches to product design and development. Increasing product complexity is forcing multiple organizations
to share in the design and development of a product. The continuing evolution of the Internet and new information
management technologies are also making this possible. Process modeling and workflow tools identify bottlenecks and
inefficiencies of design processes. Modeling and simulation tools prove out a product’s design before it’s produced. Cost
estimating tools permit cost analyses to be performed throughout the lifecycle. Requirements management tools ensure that
the product is compliant with all customer requirements. And Product Data Management (PDM) tools allow product data to
be configuration managed and shared with the distributed design team, including the customer and the supply chain vendors.
A collaborative environment for virtual prototyping and product development must therefore provide the proper
infrastructure for using these tools, as well as support the product’s development over the total lifecycle. Examples of
lifecycle phases include system definition, detailed design, manufacturing, and operational support. Each lifecycle phase will
involve different users who are dealing with a subset of the virtual prototype and potentially adding information to it. In a
virtual team environment, the users will be from different organizations in geographically distinct locations. The
collaborative environment must therefore permit the virtual prototype to be shared among the virtual team, provide
multiple domain-specific views of the product data to the proper users, and manage product configurations and baselines.
2 . Infrastructure Components
2.1. Internet Architecture
The Internet is highly scalable. It derives these properties via simple mechanisms, such as hyperlinking information across
web servers. Nodes on networks can be clients and/or servers, and each can perform the role that is necessary for operation.
The ability of enterprise agents to hyperlink to each other across the network and to travel across clients and servers will
provide essentially unlimited scalability for collaborative environments and virtual prototyping.
2.2. Product Model
An important infrastructure component for collaborative environments is a product model. The product model should
capture the product’s structure and behavior. Since the virtual prototype will be shared among the virtual team, the product
model should store only the shared data. The product model should configuration manage the product data over the entire
lifecycle and permit users to recall earlier versions of the data whenever necessary. The product model should be modular and
component based so as the virtual prototype evolves, so does the product model.
2.3. Business Systems
Business systems are the tools an organization uses throughout the lifecycle. Examples of business systems include
CAD/CAM tools, requirements tools, PDM tools, Enterprise Resource Planning (ERP) tools, cost estimating tools,
legacy and heritage tools, and project management tools. These business systems should be web-enabled or provide an
Application Programming Interface (API) that allows easy integration without a lot of customer software development.
3 . System Dynamics
Information Technologies are trending toward common systems, tools, and processes. While that is a trend away from
disjointed systems, it is unrealistic to assume that there will ever be a single process or system that satisfies every need in
an organization with multiple businesses. Figure 1 shows diminishing returns as the degree of commonality increases
beyond a limit. Figure 2 shows that hidden or ignored qualitative factors increase costs while easily quantifiable and visible
metrics decrease costs. In this example, maintenance, deployment, and integration represent quantifiable costs, while
coordination and changes and implementation delays represent qualitative factors that cause significant cost penalties in
overall solutions. Most approaches ignore qualitative factors that become important as commonality approaches 100
percent. Existing architectures for collaborative environments and virtual prototyping only account for technical aspects and
ignore cultural and organization aspects [1].
Better architectures are needed to address this dichotomy among business needs and commercial, off-the-shelf (COTS)
capabilities. The federated approach [2] to the architecture is more suited to current business trends: It provides a low-risk
alternative to existing technology investment strategies and it enables organizations to bring new technologies in a modular
fashion as opposed to the big bang approach. A federated architecture enables programs to implement a total-systems view
and to organize their supply chains at a global level.
4 . Collaborative Enterprise Environment
The goal of the Air Force’s Collaborative Enterprise Environment (CEE) dual-use application program (DUAP) was to
provide the capability for AFRL to collaborate with industry and academia on technology development programs. CEE
needed to support simulation-based acquisition (SBA), virtual prototyping and product development in AFRL’s core
technology areas of space vehicles, air vehicles, information technology, conventional weapons, directed energy weapons,
materials and manufacturing, sensors, propulsion, and human effectiveness [3].
Page 2 of 6
Disjointed
Architecture
Federated
Architecture
Centralized
Architecture
Cost of coordination,
inflexibility,
suboptimization
(qualitative, hidden)
Cost
¥
¥
¥
¥
Common Systems
Common Tools
Common Processes
Common Best Practices
Cost of deployment, maintenance,
integration (quantitative, visible)
0%
100%
Degree of Commonality
Figure 1. Federated architecture provides an optimal solution.
Cost of
Deployment
-
+
Cost of
Maintenance
Degree of
Commonality
Cost
+
+
Cost of
Change
+
+
Cost of
Coordination
Implementation
Delay
Business
Fit
-
+
+
≈
Inflexibility
-
+
B1
+
Cost of
Integration
-
+
+
Quantitative
Cost
+
Qualitative
Cost
+
Cost of SubOptimal
Solution
Figure 2. Architecture trade-off model.
Air Force goals for improved collaboration included:
• Team interaction through electronic modeling and data interchange during early design phases
• Improved capability for teams to conceptualize, develop, mature, and transition new concepts
• Improved insight into lifecycle concerns early in the development process
• Early validation of system concepts on virtual test ranges
• Maximizing synergy among various AF laboratory disciplines
4.1. CEE Design Process
A majority of AFRL’s design processes are distributed modeling and simulation tasks, which involve multiple USAF
organizations and legacy systems. These tasks often produce large amounts of design data that needs to be managed
throughout the product’s lifecycle. Figure 3 shows a typical CEE design process as a workflow. The Technology
Alternative Assessment node can have multiple subflows attached to it. The number of subflows depends on the number of
Page 3 of 6
alternative assessments needed to determine which approach produces the optimal solution. These subflows are executed
concurrently by different CEE users.
The Lethality Analysis process is common to all subflows (Figure 3) and consists of executing the SAC
(Suppressor/ALARM Context) toolset. Suppressor is a mission-level simulation model used to analyze military
operations. A typical Suppressor simulation represents a military operation, such as aircraft attacking defended targets.
Input files from the scenario, environment and type databases define a Suppressor simulation. Output from Suppressor is a
time-ordered list of events [4]. The Advanced Low Altitude Radar Model (ALARM) evaluates the performance of a groundbased radar system attempting to detect low-altitude aircraft. Its primary mission is to provide areas of detectability by a
single radar and to help the analyst understand the detectability phenomenon. ALARM input data is several data blocks that
correspond to the components being modeled. Output from ALARM is a flight-path sequence file that specifies whether or
not the target aircraft was detected [5].
F2T2E
Tech
Analysis
Requirements
Technology
Alternative
Assessment
Cost
Analysis
Lethality
Analysis
Configure
SAC
Execute
SAC
Post
Output
Off Board
Sensor
Design
Hyper-Spectral
Data
Processing
Target
Area
Assessment
Lethality
Analysis
Off Board
Sensor
Design
Improved HyperSpectral Data
Processing
Target
Area
Assessment
Lethality
Analysis
Off Board
C4I
Improved
Off Board
C4I
Figure 3. CEE design process.
4.2. CEE Architecture
A Smart Enterprise Model (SEM) was developed using the Windchill Collaborative Product Commerce tool. Windchill was
chosen as the foundational infrastructure tool for CEE based on its following capabilities:
• Web-centric tool
• Federated data model
• Lightweight web browser based interface
• Web-enabled legacy applications and databases
• CORBA support
• Rapid application development environment
The SEM is a product model that captures the structure and behavior of the virtual prototype. It’s complete in the sense that
it captures only the product data that needs to be shared among the users of the collaboration. Data that’s proprietary to an
organization is not stored in the SEM. Logically the SEM is a single entity, but since it’s implemented using a relational
database, it can physically reside in 1..N locations. The physical partitioning of the SEM is usually governed by disk
space, number of users, and database performance issues. To ensure data integrity, once product data is stored in the SEM, it
Page 4 of 6
is configuration managed throughout the product’s lifecycle. Changes to the data are stored and tracked allowing users to
recall earlier versions at any time. Configuration management is a fundamental capability of a PDM system. For CEE, the
Windchill tool provides the configuration management for the SEM data, as well as providing access control and security
capabilities. Figure 4, shown below, illustrates the SEM based CEE architecture.
Requirements
Server
Target Area
Computation Tools
Cost Analysis
Tool
Smart Enterprise Model
Sensor Design
Tools
Hyper-Spectral
Data Processing
Tools
Lethality Analysis Tollset
(Suppressor/ALARM Context)
Figure 4. SEM based CEE architecture.
The design tools (e.g. Sensor Design Tools) were integrated into CEE using CORBA (Common Object Request Broker
Architecture) to interface with the SEM. The user interface is a workflow implementation of the CEE design process
displayed in a web browser on the client machine(s). When the user executes a workflow task, by clicking on it, the
appropriate resource agents are executed to retrieve the appropriate dataset from the SEM. The design tool is then executed.
When the workflow task is complete, another resource agent is executed to store the modified dataset back in the SEM with
a new configuration. Should the user wish to compare data from a previous workflow task, or if system administration is
required, the Windchill client can be executed to provide that capability.
5 . Summary
The paradigm for virtual prototyping and product development continues to move towards a web-based collaborative
computing environment. Instead of the traditional heavyweight client/server approach to enterprise systems, collaborative
environments inspire a Web-Centric federated approach. Many vendors have recognized this trend and are making their
products more web-friendly by incorporating a lightweight client into their product that can be executed from within a web
browser. These lightweight browser clients eliminate support and maintenance costs as well as software compatibility
issues. This offers power with simplicity as mission-critical information applications are disguised as simple web pages.
There are limits to benefits achieved through commonality across distributed collaborative environment architectures.
Qualitative factors also play an important role in these trade-offs. Lockheed Martin ATL continues to research, explore, and
apply new and emerging technologies in virtual prototyping and collaborative product development.
6 . References
[1] Chadha, B., Welsh, J., “Next-Generation Architecture to Support Simulation-Based Acquisition”, American Society of Naval
Engineers (ASNE) Day 2000, May 2000.
[2] Chadha, B., “A Federated PIM for Supply Chains”, DH Brown Symposium, 1997.
[3] Stavash, J., Welsh, J., “Integrating Product Data Management in a Collaborative Engineering and Virtual Prototyping
Environment”, MCES, 1999.
[4] Science Applications International Corporation. 1996. Suppressor Release 5.4 Analyst’s Manual.
[5] Science Applications International Corporation. 1997. Operational Concepts Document (Analyst’s Manual) for the Advanced
Low Altitude Radar Model (ALARM 3.2).
Page 5 of 6
7 . Author Biography
Jeffrey Stavash is a Senior Member of the Engineering Staff. He was the lead engineer for the USAF’s CEE program, in
which he developed a collaborative prototyping environment using the Windchill PDM system. Prior to that, Mr. Stavash
developed an enterprise infrastructure for the RASSP (Rapid Prototyping of Application-Specific Signal Processors)
program to support an Integrated Product Development Environment for Digital Signal Processor systems. Mr. Stavash has
a Masters degree in computer science from New Jersey Institute of Technology and a Bachelors degree in computer science
from Seton Hall University. He is also a member of the Association for Computing Machinery (ACM).
Mr. Welsh manages the enterprise technology organization, leading collaborative engineering projects for ship systems,
mission-level analyses, and logistics supply chain improvement. He has over 20 years technical and managerial experience
on enterprise software, systems engineering, and electrical engineering. He has a Bachelors degree in electrical engineering
from Villanova University and a Masters degree in systems engineering from the University of Pennsylvania.
Dr. Chadha is the principal investigator on enterprise engineering, supply-chain integration, and process improvement
initiatives within Lockheed Martin. He leads the SPM architecture team for Lockheed Martin’s DD 21 program. Dr. Chadha
is a member of the ASME Engineering Information Management Committee, the Supply Chain Council, and chairs
Lockheed Martin’s PDM Interfaces Working Group. He received his Ph.D. in Mechanical Engineering from Georgia
Institute of Technology.
Page 6 of 6