Architectural Framework to Support Integrated
Concurrent Engineering in an Academic Institution
By
Bruce J. Farnworth
B.E. Mechanical Engineering
The City College of New York, 1998
SUBMITTED TO THE DEPARTMENT OF AERONAUTICS AND ASTRONAUTICS
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF ENGINEERING IN AERONAUTICS AND ASTRONAUTICS
AT THE
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
June 2000
@ 2000, Bruce J. Farnworth, All rights reserved
The author hereby grants to MIT permission to reproduce and to distribute publicly paper
and electronic copies of this thesis document in whole or in part.
Signature of Author:
Bruce J. Farnworth
Department of_.eronautics and Astronautics
May 18, 2000
Certified by:
i
Certified by:
bCharles
W. Boppe
Senior Lecturer, Department of Aeronautics and Astronautics
Thesis Supervisor
,Cory
R.A. Hallam
Lead Project Engineer, Department of Aeronautics and Astronautics
Thesis Supervisor
Accepted by:
Nesbitt W. Hagood
Associate Professor of Aeronautics and Astronautics
Chairman, Committee of Graduate Studies
SW 0 '7Z0O
(-.IBRARIES
Architectural Framework to Support Integrated
Concurrent Engineering in an Academic Institution
By
Bruce J. Farnworth
Submitted to the Department of Aeronautics and Astronautics on
May 19, 2000 in Partial Fulfillment of the Requirements for the
Degree of Master of Engineering in Aeronautics and Astronautics
Abstract
This thesis focuses on developing a recommended architecture for the next generation of
design centers for integrated concurrent engineering in an academic environment and
identifying and implementing an enabling sub-system for the architecture. During the
development of this architecture a systems engineering process was used to structure the
efforts of the team and maintain traceability to the customer needs throughout the design.
Site visits were undertaken to benchmark existing design centers. Customer needs were
compiled and analyzed to develop the system requirements that were input into a product
matrix. This enabled the team to generate a wide array of implementations to synthesize
multiple architectures. The recommended architecture should help to promote active
learning in a distributed design team environment. Further, a concept for an On-Line
Teaching Assistant (OLTA) was developed designed to help designers throughout the
process of developing complex systems. The OLTA may be considered an "expert
system" that will retain and filter an accumulating knowledge database of student work
entities. A proof-of-concept prototype was developed to demonstrate this concept.
Results of the architecture show a significant relative improvement over the currently
proposed architecture and preliminary responses for the OLTA are very positive with one
advisor stating "OLTA could revolutionize engineering education as we know it." Two
faculty members agreed to utilize a prototype in their upcoming classes and the
Aeronautics and Astronautics Department is very interested in implementing the system
in its capstone design classes.
Charles W. Boppe
Thesis Supervisor:
Title: Senior Lecturer, Department of Aeronautics and Astronautics
Thesis Supervisor:
Cory R.A. Hallam
Title: Lead Project Engineer, Department of Aeronautics and Astronautics
2
Table of Contents:
1. Abstract
2
2.
Introduction
7
3.
Background: The New Paradigm of Design Centers
9
4.
Methodology
12
5.
DE-ICE Mission Statement
17
6.
Needs, Expectations and Requirements
19
7.
Architectural Synthesis
38
7.1
Concept Development
45
7.2
Concept Evaluation
52
7.3
Baseline System Architecture
55
7.4
Baseline Product Development Process
58
8.
Prototype Development and Demonstration
59
9.
Assessment and Recommendations for Future Work
86
10.
Conclusions
90
11.
Acronyms
92
12.
References
94
13.
Appendices
97
3
List of Figures:
Figure 6-1 Hierarchy of User Need
20
Figure 6.1-3 Distribution of the Modeling Resources
27
Figure 6.1-4 Components of the DOME System Architecture
28
Figure 6.1-5 A Collaborative Framework
29
Figure 6.1-6 Conceptual Diagram of VSLCDE
30
Figure 6.2-1 DE-ICE QFD Requirements Matrix
32
Figure 6.3-1 System Use Case Diagram
36
Figure 6.3-2 Design Use Case Diagram
37
Figure 7-1 DE-ICE QFD Product Matrix Page 1
39
Figure 7-2 DE-ICE QFD Product Matrix Page 2
40
Figure 7-3 DE-ICE QFD Product Matrix Page 3
41
Figure 7-4 DE-ICE QFD Product Matrix Page 4
42
Figure 7-5 DE-ICE QFD Product Matrix Page 5
43
Figure 7-6 DE-ICE QFD Product Matrix Page 6
44
Figure 7. 1-1 Software and IT Architectural View for the Author's Architecture "A"
46
Figure 7.1-2 Equipment Architecture View for the Author's Architecture "A"
49
Figure 7.1-3 Physical Architectural View for the Author's Architecture "A"
51
Figure 7.3-1 Final DE-ICE SW/IT Architecture View
56
Figure 7.3-2 Final DE-ICE Equipment Architecture View
57
Figure 8-1 OLTA Vision
60
Figure 8-2 OLTA Use Case Diagram
65
Figure 8-3 OLTA Interface Relationship Diagram
66
Figure 8-4 Top-Level OLTA FFD
69
Figure 8-5 FFD for Blocks 3
71
Figure 8-6 FFD for Block 4
72
Figure 8-7 FFD for Blocks 9
73
Figure 8-8 FFD for Block I1
74
Figure 8-9 OLTA Preliminary Faculty User Interface
75
Figure 8-10 Preliminary Student Interface
76
Figure 8-11 OLTA Prototype Development Use Case
80
Figure 8-12 OLTA User Interface
82
Figure 8-13 Prototype Physical Implementation
83
Figure 8-13 OLTA Development Process
84
Figure 8-12 OLTA Production Server Architecture
89
4
List of Tables
Table 2-1 Priority of Classes for DE-ICE Development
8
Table 5-1 DE-ICE Mission Statement
17
Table 7-1 Product Matrix Architectural Evaluation
38
Table 7.2-1 Pugh Matrix
53
Table 8-1 Prototype Evaluation Matrix
61
Table 8-1 Prototype Work Package Descriptions and Break Down
68
Table 8-2 Content Type and Attributes
77
Table 8-3 Content Providers
78
Table 8-4 Content Consumers
79
Table 8-5 Access Control
79
5
Dedication:
This thesis is dedicated to my wife for her unending support, understanding and love.
Acknowledgements:
The author would like to thank the following people for their help and support on this
project: Mr. Cory Hallam, Mr. Charles Boppe, Dr. Dava Newman, Dr. Billy Fredriksson,
Mr. Gunnar Holmberg, Mr. Fred Donavan, Mr. David Mitchell, Dr. Robert Shishko, and
Dr. Joel Sercel. Additionally I would like to thank my teammates Mr. Alex Manka and
Mr. Simon Nolet for their support in pursuing this project and their professionalism
during the execution of this project.
6
2. Introduction
The
Massachusetts
Institute
of Technology's
Department
of Aeronautics
and
Astronautics has recognized a need for a revolutionary change in the way students are
taught [15]. Traditionally, instructors have taught with a discipline-specific methodology
which allow students few opportunities to understand the interactions of each discipline
in design, manufacturing, and systems integration processes.
In addition, industry has
indicated the desired attributes of graduating engineers to include [20]:
i)
A good base of engineering fundamentals
ii)
Understanding of the design and manufacturing process
iii)
Multi-disciplinary "systems perspective"
iv)
Good communication skills
v)
The ability to think critically and creatively
vi)
Flexibility to adapt to rapid and major change
vii)
Understanding of the importance of team work
Today MIT is embracing the Conceive-Design-Implement-Operate (CDIO) theme as the
context by which an engineering education is to produce graduates that address these
issues by designing and manufacturing a product in a team environment.
Examples of the changing pedagogy in the Aeronautics and Astronautics Department are
the implementation of the CDIO philosophy and the use of active learning methods in
design classes [15]. Development of the Design Environment for Integrated Concurrent
Engineering (DE-ICE) is part of the process to create active learning in a design
environment. This initiative seeks to "create a more stimulating hands-on environment
for students (thus improving student motivation, understanding and retention) [15]."
The Aeronautics and Astronautics Department is creating a "cultural shift" in education,
whereby students and faculty consider learning to be integrally linked with active
engagement and interaction instead of relying on passive learning through lectures [2].
7
This pedagogical shift aims to produce engineers that understand the complex and
iterative nature of holistic product design and also gain a deeper understanding of the
engineering fundamentals they have learned by using them.
To address this change the Aeronautics and Astronautics Dept. has planned to develop a
world-class Design Center (DC) enabling students to perform integrated concurrent
engineering. This center will be used by undergraduate (UG) and graduate (G) students
for lectures/presentations, large systems design, research design support, collaborative
design with external teams, design-based distance learning and teaching, and interactive
electronic classes.
Priority
1
Short Term
16.82 Flight Vehicle UG
16.83 Space Systems Engineering UG
2
16.89 Space Systems Engineering G
16.90 Aircraft Systems Engineering G
3
Long Term
16.684 Experimental Capstone
Subject UG
16.870 Master of Engineering
Project G
16.00 Introduction to Aerospace and Design UG
Table 2-1 Priority of Classes for DE-ICE Development
Table 2-1 shows the immediate priority of the classes targeted for the DC. The project
time frame is defined as short term (one week to one semester) or long term (1 to four
semesters). Please see Appendix H for active learning course descriptions.
8
3. Background: The New Paradigm of Design Centers
As aerospace systems become more complex with the constant need to produce quality
products faster and at lower life cycle cost, more and more industry organizations are
turning toward integrated concurrent engineering with the assistance of information
technologies. NASA, Saab AB, Boeing, and The Aerospace Corporation have developed
DC's and distributed integrated tools to support integrated concurrent engineering. At
these organizations a holistic design process stressing the complete process over time is
beginning to replace the traditional product development processes (i.e. the over the wall
process). This is accomplished through use of the appropriate tools key to their success
such as development methods, integrated modeling, and engineering management [16].
Generating designs for a complex system involves decomposing the design problem into
sub-problems that can be analyzed by a small team of engineers. This allows engineers
who possess the needed core competencies to solve specific areas of each sub-problem
[9].
However, generating a holistic design that addresses the trade-offs of cost,
performance, etc. and different goals of each sub-problem can be very time consuming,
and often involves multiple iterations of the design. Inferior decisions can also be made
if the sub-problem interactions are not fully understood. Additionally, experience has
proven that 70-80% of a system's cost is committed during the initial conceptual
development phase of the design, thus the conceptual development phase offers the
greatest opportunity to influence the life cycle cost of the system [17]. The current trend
towards integrated concurrent engineering is to enable aggregation of the sub-problem
analyses into a whole "system" for analysis and trade studies early in the design process.
This aggregated system model would consider the lifetime of the "system."
NASA has set out to meet these goals by initiating development of an Intelligent
Synthesis Environment (ISE) that integrates advanced computing with human interaction
(in the computer environment) to create a seamless environment enabling new levels of
productivity among distributed collaborative teams [1]. NASA's first step towards the
9
ISE vision is the Product Development Center (PDC). In developing the PDC, Integrated
Product Development (IPD) teams have been able to complete proposals and mission
analyses with "savings of up to ten times the previous cost" in dedicated week-long
sessions instead of during the span of several months [18].
Saab AB's goals sought to reduce life cycle cost, time and the number of defects by 50,
50 and 20 % respectively for the development of the two-seat version of the Gripen and
the Saab 2000 [17]. Aspects of the development process used at Saab are [4]:
e
Easy access to information and knowledge
e
Extensive use of modeling and simulation to provide knowledge
e
Support engineers in preliminary development stages to allow for mature
decisions as early as possible
e
Support and simplify communications
e
Provide a channel for engineers and experts to utilize their expertise in an
efficient manner
Saab AB has implemented a company-wide distributed database with integrated
engineering processes to allow collaborative and concurrent work. Design centers were
created which allow IPD teams to meet and actively work together to reach design
decisions. Designs can be accessed and viewed in their context by the team along with
additional information such as simulation and analysis results, scheduling information,
and Bill of Materials (BOM).
An application (DIP) was created to record meeting
minutes and to provide for "screen grabbing" opportunities of any information or
drawings. It allows engineers to add annotations into the system in real-time, enables
team leaders to assign responsibilities, and to retain and enhance knowledge of the
decision making process while fostering communication.
During the introduction of
Saab's change in engineering process, there was some hesitation from the engineers but
now the general consensus is that it is working "very well" was relayed during personal
interviews at the site visit in February 2000, and have met or exceeded their goals stated
above[17].
10
However, DE-ICE is driven by different goals and constraints than industry. With the
shift towards an active learning paradigm and the CDIO philosophy students will be
encountering real world design problems involving cross discipline knowledge. One goal
is to enhance core fundamental knowledge while introducing students to the iterative
nature of developing products that span a very wide range of complexity. A second goal
of DE-ICE is to promote active learning in a design environment by enabling students
and faculty to work in distributed design teams concurrently, along with external design
groups to develop and design complex products.
The primary distinction between industry and academia is that students cannot become
dedicated IPD group members spending all of their time on a single project due to the
requirements of other classes and the scheduling conflicts that this would impose.
Additionally, most junior students using the system may not have the expertise of
working engineers and may find it difficult to perform well in an unguided IPD
environment.
To overcome this problem the DE-ICE architecture must provide a robust
communication and collaboration infrastructure that allows students to work along with
the demands of their varying class schedules, and act as a resource to help students
accomplish their tasks.
11
4. Methodology
During the course of the team's research and design period, a process was used to
structure the effort and to provide a logical framework. The formal methodology used
during the DE-ICE architectural concept development is described in the following
sections.
During the course of the project, communication was integral as a means to
perform work and test technologies and ideas of the team which enhanced overall
interaction and spirit.
MS NetMeeting, group emails, Virtual Network Computing
(VNC), and Distributed Object Modeling Environment (DOME) were tested and
provided insight into some of the limitations of these applications and techniques (please
see Manka [30] for information on the testing of these tools).
Define Project Scope:
The first task undertaken was to define the scope of the project.
This project was
considered to be very complex, as pointed out by Mr. Gunnar Holmberg, manager of the
advanced technologies department. The team realized that boundaries must be set at the
beginning of the project to help guide and focus the design team. A mission statement
was developed that defined the project and set achievable goals for the team to work
towards [8]. The users of the system were defined, along with possible constraints and
stakeholders on the project.
Literature/Technology Search:
Literature and technology searches helped the team to develop a better understanding of
the problem undertaken.
Searching existing literature and technology ensured that the
system architecture developed would build on, but not repeat the efforts conducted by
other researchers and organizations.
This project utilized patent searches, Internet
searches, library and journal publications, and organizational best practices (i.e. site visits
to observe how others are meeting similar goals) to uncover and understand the state-ofthe-art in integrated concurrent engineering.
Data collected in this effort was also
important during the benchmarking phase of requirements definition. This process also
12
helped identify potential sub-system components that may be utilized in the system
architecture.
Survey Potential Users:
For this project the customers of the DE-ICE system were defined as the end users. This
would include internal and external students, faculty, guest lecturers, teaching assistants,
and the AA staff. Two surveys were used to gather the varied needs of the end users.
Students, staff and faculty were surveyed with issues such as system usability, ease of
accessing data, and team communication. In addition, faculty were surveyed on how they
plan to use the system to enhance their delivery of course material to help students gain a
better understanding of the course goals, and for the design team to understand the
teaching processes that may be used with the system.
The student and staff survey was more general so that the results would mark the
preference of the end users. Personal interviews were conducted for the faculty survey
while the general survey was Internet-based.
At the recommendation of Professors
Newman and Boppe the survey format was selected, due to i) possible low return rate
from the faculty, ii) the importance of getting feedback from the faculty. Copies of the
surveys may be seen in appendix C.
Needs and Requirements Analysis:
Key to the success of this project was the proper identification of the customer needs and
focusing on the ones most important. Correctly translating the customer needs allowed
for the generation of the systems technical requirements, a process matrix, and ultimately
the system architecture. To correctly capture the voice of the customer, Quality Function
Deployment (QFD) was used to help eliminate any personal biases that may be
introduced by the team members [26].
QFD helped the team to identify the highest
technical requirements of the system while minimizing personal biases of the design
team. Requirement conflicts were also identified and monitored.
13
Benchmarking Existing Systems:
Site visits provided information on state-of-the-art integrated concurrent engineering
design environments. System architectures and top-level design processes of the existing
facilities were gathered and analyzed for use in competitive benchmarking. Collected
data was used in the QFD matrix to allow the team to set goals to match or exceed the
systems benchmarked.
Use Cases:
Object-oriented methods such as Use Case Diagrams helped the team to understand the
context in which the system would be used and to identify possible operational
interactions that the team may have inadvertently neglected. Use cases identify the actors
using the system, the use instances and how functionality is extended. The Use Case
Diagram also showed the relationships between the actors and the use cases or
functionality of the system along with any interfaces [19].
Product Matrix:
The product matrix acted as a map of the highest technical requirements from the QFD
into implementations that can satisfy the requirement of the system. Use of a product
matrix allowed the team to characterize multiple implementations for each technical
requirement.
It can also allow for requirements traceability for future design
enhancements to the DE-ICE system.
Architectural Synthesis:
Architectural variants were generated from the product matrix by selecting subsets of the
implementations generated in the product matrix.
Multiple "views" (i.e. physical,
software/IT, schematic Block diagrams) of the architectural concepts were used along
with the product matrix for a convergent/divergent total design concept [5] that will meet
the user needs.
14
With the variants and baseline architecture identified, a Pugh matrix was used to identify
the concept, which as a whole met the selected decision criteria. Ranking was achieved
through engineering judgments of the increased, decreased or similar performance that a
particular architectural criterion would yield relative to the baseline.
A Pugh type
analysis was used because it could yield good results during the conceptual design phase
when detailed analysis of cost and functionality may not yet be adequately analyzed.
Baseline for the Pugh matrix was the existing and planned design center in the
Aeronautics and Astronautics Department. A Pugh matrix also allowed the design team
to identify aspects of each architectural variant that would show significant improvement
over the baseline.
Results from the Pugh matrix were used to synthesize additional design concepts that
capitalized on the increased performance aspects of each concept from the previous step.
The goal was to identify an architecture that would show increased performance when
judged against all of the decision criteria.
Prototyping:
Throughout the process of synthesizing the architectures the team maintained focus on
creating or combining elements that would prove to be critical and novel prototype
options. Prototype concepts were evaluated against the driving technical requirement to
provide a well-founded justification for the selected concept.
Due to the team's size and constraints of the term boundary, prototyping demonstrated a
sub-set of the enabling functionality.
Therefore, the prototype acted as a proof-of-
concept demonstration with follow-on work to be performed after the project.
Project Planning:
Initially, the team planned two days per week to meet and discuss individual work
accomplished during independent work time. Major tasks for the project were defined,
and the team tried to evenly distribute the workload. Using MS Project 98 helped to
15
facilitate project planning (see appendix G for the detailed project schedule).
Three
design reviews acted as choke points to keep the team focused. Industry representatives
were invited to attend and give feedback on the work completed and the direction of the
project.
16
5. DE-ICE Mission Statement
To launch the DE-ICE project a mission statement was drafted to identify the system
context along with a basic description and goals of the project. The mission statement
shown in Table 5-1 helped the team identify three of the six attributes of the DE-ICE
system [23], namely: why the system is being built, what the system should do, and who
will be doing it.
Description
"To develop an operational framework for a design center to enhance learning in
an academic environment."
Context
DE-ICE will be used in an academic environment to enhance the learning of the
process of conception, design, implementation, and operation of complex
aerospace systems.
To develop recommendations for To discover a key enabler of the system and
prototype a component.
the architecture of the design
environment.
Possible external users:
Internal:
Guest lecturers
MIT Students
Industry representatives
Teaching Assistants
External students
Faculty
Staff
The system will use existing computer
The system should utilize mature
hardware.
technologies.
Goals
Users
Assumptions
Stakeholders
End Users (MIT students)
MIT A/A Department
Microsoft Corporation *
Industry
Table 5-1 DE-ICE Mission Statement
The asterisk next to the Microsoft Corporation indicates that they were initially
considered a primary stakeholder, considering the substantial funds they provided to the
department for research. Microsoft showed interest in the project during the prototype
phase and was very helpful.
17
Using the mission statement helped the team remain focused and not get overwhelmed by
the scope of the task. Initial documentation of the design team goals clearly defined
project deliverables. Additionally, when presenting at the Architectural Design Review
(ADR) the team was able to show that it had successfully completed its first goal and had
identified a component of the system to prototype.
18
6. Needs, Expectations and Requirements
One of the most difficult processes undertaken during the project was discovering
customer needs. The customers for the system are defined as faculty, staff, and students
of the Aeronautics and Astronautics Department who will be the majority of the end
users. Difficulty in defining the needs was due to the fact that the ultimate uses of the
system were somewhat uncertain, teaching processes that would be used were undefined,
and there was a limited base of experienced end users.
During the initial stages of this project the highest level needs defined by the Aeronautics
and Astronautics department were:
1) The system should be scaleable for varying levels of user experience and training
2) Enable a distributed design team to concurrently design aerospace systems
3) Add value to the engineering project and enhance previously learned knowledge
Upon review and suggestions from the group advisors, the team tried to reassess the
system needs. Further consideration, refinement and iteration led the group to create a
hierarchy of system needs. A description of the system needs and weighting factors may
be found in Appendix A. The customer needs are as follows:
Pedagogical Needs
*
Capability to support MIT operational modes (system constraint)
e
Active learning in a design environment
" Holistic view of design
*
Improved knowledge of and experience with the design process
e
Support of life cycle analysis
Operational Needs
*
Improves the quality of student design work
19
e
Increases productivity for a given amount of time
*
Highly useable system
*
Support for team enablers
*
Flexible system (Sustainability)
The high-level needs are categorized as Pedagogical and Operational under which are
reflected the primary system needs.
A graphical hierarchy of needs was created to
indicate needs prioritization, and is shown in Figure 6-1.
DE-ICE Needs
Hierarchy
Capability to support
MIT operational
modes
Active learning in a
design
environment
Holistic view of
design
improve
knowledge of and
experience with the.
design process
Support of life
cycle analysis
Increase productivity
for a given amount
of time
Highly useable
system
Support for team
enablers
improve the quality
of student design
work
Sustainable system
Figure 6-1 Hierarchy of User Need
20
6.1
Survey of Existing Systems
Integrated concurrent engineering design environments evaluated for this study can be
classified into two groups, those used for:
i)
Conceptual design,
ii)
Product engineering/manufacturing
The following is a brief description of the systems surveyed. Additionally the team has
reviewed several core technologies that may be mature enough for system utilization.
Concept Design Centers (CDC) are mainly focused on developing conceptual designs
and proposals for complex space systems. Goals of the CDC's are to reduce the time and
cost needed to develop a design or proposal. To date, they have shown great success in
meeting their goals as will be explained in the following sections [18].
NASA JPL PDC:
NASA's Product Design Center (PDC) is used for generating and analyzing conceptual
designs for space missions. NASA has reduced the design cycle time to one-tenth the
traditional engineering process while reducing cost from 250K to 50K [18]. A dedicated
team of functional engineering leads for each sub-system is used during design sessions.
Preliminary work is undertaken off-line by each sub-system lead so they are fully
prepared when the design session begins. Design sessions are led by an overall team
leader and are highly scripted and timed. Sub-system models are integrated into one
Excel spreadsheet for global cost/performance optimization and decision-making.
System architecture for the PDC and top-level process can be seen in appendix D. For
more information on the PDC please see [30,31].
TRW/Aerospace Corp.:
TRW and the Aerospace Corp. concept design centers are very similar in usage and
functionality to the NASA PDC and are in fact outgrowths of the PDC. These newest
design centers use linked MS Access databases to increase flexibility. For a more in-
21
depth analysis of these facilities see Appendix D. For more information on the these
DC's please see [30,3 1].
California Institute of Technology:
Dr. Joel Sercel, who was one of the driving forces in the development of the NASA PDC,
is using the concept of integrated concurrent engineering to teach Space Systems Design
at CalTech.
The students are supplied with all the equations needed to design and
analyze a space system.
Students use UML to develop the system's top-level
requirements.
ICEMaker is used to identify subsystem interfaces early in the design process so that
students only create the models they need for their analysis [27]. ICEMaker is a LAN
distributed Excel spreadsheet and database. Subsystem groups log into ICEMaker and
build their models on a local sheet. When a model is complete the resulting outputs are
published to the "System Sheet" which integrates the multiple distributed sheets (or
models) [27]. ICEMaker incorporates a Product Attribute Database (PAD) that is used to
integrate the subsystem models.
It supports external interfaces with Excel, Matlab,
DrawCraft, and CAD STEP files.
The students spend twelve weeks building the system models and three weeks performing
design trade studies.
Saab AB:
The site visit to Saab AB focused mainly on the area of detailed design of airframe
structures and system integration. Saab AB has turned to simulation, modeling, and the
use of Digital Mock-Ups (DMU) to greatly reduce the time needed to verify the subsystems requirements to the allocated baseline requirements [24]. An organization-wide
product definition database serves as a baseline from which all IPD team members can
work using discipline specific tools. Simulation is used extensively during the design
22
process to verify manufacturing, assembly, maintenance, and later in the life cycle, for
customer support.
Three design centers and an application to capture meeting minutes were implemented to:
" Decrease the time from design to decision
e
Increase the rate of communication for the IPD team members
e
Move decision making down to the lowest level possible
*
Postpone generating drawings as long as possible
e
Capture the design knowledge and carry it forward with the design [32].
The meeting minutes application, known as "DIP" (a Swedish acronym), is a method for
carrying knowledge along with the design. DIP can also be thought of as a decision
database as it is accessible to all project engineers on-line before and after a meeting. It
is used to set the meeting agenda and to assign explicit responsibilities to team members.
DIP has also been found to be very useful in documenting the designs.
Please see
Appendix L for more information on the "DMU Rooms." The system architecture and
structural analysis and modeling process followed at Saab AB can be seen in Figures 6.11 and 6.1-2 respectively [23].
During the analysis of the data from the site visit it began to appear that Saab has
implemented many of the Lean Enterprise Model enabling practices [29]. Key practices
that were believed to be identified are:
e
Assure seamless information flow
e
Make decisions at the lowest level possible
e
Implement integrated product and process development
23
Video
Switching
Video
RGB
Video
eo
put
- Ii
I
L_
-I
Video
AUX Video
input
Design Centers
Unix Workstations
distributed throughout
FTP to external
vendors
Figure 6.1-1 Saab Design Center Architecture
24
A structural modeling process followed at Saab is an iterative loop that is used to verify
the sub-assemblies to the allocated baseline. Modeling analysis flows from a CATIA
model of the aircraft perimeter. Computational fluid dynamics is used to determine the
load distribution and a load case is defined for input into the structural models developed
in I-DEAS. NASTRAN is used for finite element analysis of the structure. Landing and
flight dynamics are then incorporated into the load cases and the process is iterated to
refine the detailed design and structural sizing. Additionally, as the program matures
load cells are incorporated into the test and production craft to continuously validate,
refine, and update the models and the load cases used in the simulations.
CATIA
CFD
1-DEAS
Loads
NASTRAN
Dynamics
Key to this
analysis is good
definition of load
cases
Detail design sizin(
Figure 6.1-2 Saab Structural Analysis and Modeling Process
25
Core Technologies:
Existing systems that could be utilized in the DE-ICE architecture were researched to
gain insight into their functionality, level of maturity and usability. DOME which was
developed in the MIT CAD-LAB, and IMAGE developed at Georgia Tech were
researched and are summarized below.
DOME:
Distributed Object-based
Modeling and Evaluation (DOME) enables the rapid
construction of integrated design models to improve product quality and reduce
development time. DOME allows different engineering applications and design models
to interact in a common environment [9].
Modules are created that encapsulate
engineering models, data, or software applications. These modules or objects can then
interact with each other through services over the World Wide Web (WWW) thus
allowing for the exchange of information. Interactions between modules are achieved by
publishing and subscribing to services that can be remotely provided through the WWW
[11].
DOME enables aggregation of the individual sub-problem objects, simulation execution,
and analysis of the whole system no matter where the objects reside or what disciplinespecific tool was used to create it. Further, since each sub-problem is a stand-alone
module there is a potential for model cataloging and reuse. Individual objects can be
integrated using relationships that define their interactions.
Figure 6-3 shows how
individual distributed objects are aggregated into sub-system modules and then into a
holistic system for a simple cordless drill.
A key feature of DOME is that it allows a design to evolve over time by allowing the
system designers to define modules (declaring the services it can provide) without
implementing the embedded model.
Initially a model can be defined by a simple
26
function that the sub-problem is expected to emulate [10] and can be further refined over
time.
Informtion Broker
Gear Manufacturer
\etwork Backbone
(i.e. internet, WWW, etc.)
Network Backbone
(i.e., Internet, Intranet. etc.)
Drill Division
Consuner Ekectronic Company
Figure 6.1-3 Distribution of the Modeling Resources
(From: Modeling and Evaluation of ProductDesign Problems in a DistributedDesign
Environment)
DOME includes design optimization tools for system evaluation. Evaluation models can
be embedded into the modules to provide evaluation services that facilitate observing
quality and evaluating alternates from different viewpoints. Evaluation services include
probability acceptance modeling, Design Structure Matrix (DSM), neural networks,
Genetic Algorithms (GA) for system wide optimization, and multi-dimensional spider
graphs to indicate the effects of trade-offs.
27
DOME uses a three-tier, distributed, object modeling architecture consisting of a client
GUI, DOME server, and model repository that interact using a standard CORBA
interface. Figure 6.1-4 shows the main system components of the DOME architecture.
DOME server interface
interrace/
pointer
pointer of an interface
requests for a service
Figure 6.1-4 Components of the DOME System Architecture
(From: A Web Based CollaborativeDesign Modeling Environment)
IMAGE:
Georgia Tech is currently developing a collaboratory framework called Intelligent
Multidisciplinary
Aircraft
Generation
Environment
(IMAGE).
Collaboratory
frameworks are defined as integrating disparate domain analysis tools, management of
complex systems, communication of design information, and human distributed decisionmaking [12].
IMAGE is a multi-media based, designer-oriented, collaborative
framework where simulations, teams, and teammates interact as shown in Figure 6.1-5.
28
Collaboratories
r ------------------------------------------------Domain
Analysis
A
<
Management
Domain
Analysis
<
C
Figure 6.1-5 A Collaborative Framework
(From: Enabling Advanced Design Methods in an Internet-Capable Framework)
Seven functional components which include database functionality, process management,
and advanced design functionality are designed to facilitate modeling, simulation, and
design along with a Lean-Server concept make up the backbone of IMAGE.
IMAGE
currently supports technology assessment, design method integration, and distributed
simulation [13].
IMAGE is currently used as the prototype architecture for the Virtual Stochastic Life
Cycle Design Environment (VSLCDE), which is designed to facilitate decision-making
over time. Figure 6.1-6 shows the relationships of the five major elements undertaken
when a design project commences [14].
"
Problem formulation
*
Life-cycle modeling
*
Integration
*
Decision support
29
e
Decision making
Please see Elements of an Emerging Virtual Stochastic Life Cycle Design Environment
for a more detailed description of VSLCDE.
Problem Formulation
Decision
MA ing
Figure 6.1-6 Conceptual Diagram of VSLCDE
(From: Elements of an Emerging Virtual Stochastic Life Cycle Design Environment)
Research Findings:
Site visits and research revealed that the IPD teams use dedicated team members and in
some instances functional team leaders in their integrated concurrent engineering
sessions. The NASA PDC sessions are highly scripted to maintain team focus. Meeting
notes and annotation are collected in real time during the design session.
30
Saab uses the DIP application to structure meetings, assign responsibilities, and to retain
organizational knowledge in the form of the decision database. The DIP meeting notes
also considered official design document. The design rooms allow interactive design
sessions of the IPD teams that increase the communication between team members. Saab
is mainly focused on communication of the design teams instead of integration of design
tools. This is due to the fact that as systems become more complex, a single engineer
may no longer comprehend the complexity.
*
Communication is a driving factor in all organizations studied
e
Communication and documentation are integrally linked in these systems
e
Team member with little initial stake in the design can make very good
documenters and will get drawn into the process
e
Need to consider the clock-speed of typical software packages used and support
from vendors (normally
-
1.5 years)
e
Plan for upgradability of the software systems
e
All ICE sessions are heavily dependent on a team leader to maintain focus, tempo
of meetings, consideration should be given to short training session for the team
leads
In academia possible problem that may arise are:
e
Inexperienced engineers may have difficulty developing good first order models
e
Maintaining balanced teams to help optimize globally may not be possible
e
Remembering that decisions are still made by humans
31
6.2
Technical Requirements
System Technical Requirements (TR) were filtered down from user needs through QFD.
A QFD requirements matrix was generated and iterated to properly capture the highest
technical requirements. Due to the limited time of this study only the highest priority
technical requirements were used to develop the system architecture.
The QFD
requirements matrix is shown in Figure 6.2-1.
2x
x'
<
X,
X
>
x
X
X,
x
Req
u Iremnt,
E
\Technica
Cu-1me Need.
Active Learning In
Environment
a
Design
Holistic View of Design1Kowldgeofand
Exeinewt h
eIgn Process
Support of Life Cycle Analysis
Quality of Student Design
Work
impove
Improved
10
9
9 19
3
9
9
9
8
5
3
3
39
1
3
1
8
1
3
increased Productivityfor Given
Arnount of Tirne
7
3
9
Support For Team Enablers
7
j
9
3
1
9
1
1
1
1
3
9
3
3
1
1
3 131
1
1
1
3
1
3
1
3
3
1
3
3
1
3
9
9
3
Capabilityto SupportMIT Operational
Modes
N/A
TR Importance W*_
RelativeWeight (%)
_t
1
3
1701
98
2
4
8
3
287 122
3
1
3 3
1112811271
3
3
Units
3
3
3
1
45
54
68
14
7
6
5
2
1
1
1
3
9
9
9
9
3
1
1
3
1
3
1
1
9
1
1
9
9
9
9
9
9
_4
1
32_
28
9
3
3
1
130
3
5
3
9
3
1
106
1
3
3
1
56
3
3
9 3
1
13
3
1
12
12
1
9
9
91
3
1
31
132 122 105 113 117 107
3
1
1
1
4
Highly Usable system
73 _98
5
4
1 1
1
3
54
84
54
45
6
4
6
7
.
3
74 i44
5
3
61
56
3
9
72
32
5
10
74
0
at
X
Target Values
-
Saab
>1
8
NASA, Aerospace, TRW
>2
7
CalTech
>4
DOME
1
1
3
9
Sustainable System
Constraint
3
>2?
_7
4
1
2
>4
1
0
161
0
1
1
6
1
1
2
inf
>6
3
>4
0
1 min
7
<1
4hr
11
1
2
IMAGE
Figure 6.2-1 DE-ICE QFD Requirements Matrix
User needs, categorized as pedagogical and operational are inserted on the left side of the
QFD matrix.
Ranking factors that were defined and agreed upon by the team and
32
representatives of the Aeronautics and Astronautics Department are listed just to the right
of the user needs. The main body of the QFD matrix is the relationship matrix area
where each technical requirement is assigned to a column and evaluated against a need.
Next, a decision is made as to the importance relationship of each TR. This determines
the relationship of a TR to a specific need. Relationships to the needs are weighed on a 9,
3, or 1 scale depending on a strong, medium, or low relationship respectively. Each TR
weighting factor is multiplied with the ranking factor of the needs and summed in the
bottom of the TR columns to give a total importance score for the TR. Directly beneath
the total score is the relative importance score of the TR.
Measurable units used to specify each TR are located at the upper portion of the lower
section. Under this is a benchmarking section where each existing system that contains a
comparable TR is rated to allow for a goal to be set for the DE-ICE system.
The QFD matrix generated seven TRs: four from the highest ranked and three that ranked
strongly against the single constraint. A sensitivity study conducted on the QFD matrix
revealed a borderline TR which was carried along with the original seven. The TRs for
the system are (in order of importance):
1. Design and analysis support
System should provide the hardwareand software tools the students need during
the design and analysisprocess.
2. Provide guidance throughout the design process
Give students access to information, examples, theory, etc. which should provide
a roadmap through the life cycle of a product design.
3. Planning and management of the design process
Help students define, schedule and monitor tasks, deliverables between tasks and
the progress of theirproject.
4. Experimentation support
33
Support of the design, implementation, analysis and integrationof results of
experiments, including resources and tools that will help students interface with
computers, machines, controllers,etc.
5. Operate on any platform
Give the students andfaculty the ability to work in any environment (UNIX, Mac,
PC operatingsystem).
6. Distance collaboration support
Provide remote capabilityto attenda class, easily interactwith remote teammates
and access external resources (specialists,professors, etc.).
7. Flexible system
Have the ability to adapt easily to different operationalmodes, subjects, projects
or new technology.
8. Presentation and reporting support
Provide students the capabilityto effectively presentand report theirprogress
and results.
These TRs were used in the QFD Product Matrix to synthesize possible architectural
variants for the DE-ICE system.
The top section or "roof" of the house of quality is the correlation matrix that was used to
determine the conflicts between the TRs (Boppe [25]). The main conflicting TRs are:
e
Design and Analysis Support vs. Operate on Any Platform
Due to the large variety of software tools and operatingsystems special care
would be needed to ensure that the system could operate on any type of platform.
e
Design and Analysis Support vs. Flexible System
Tight Integrationof design and analysis tools that will support the life cycle of a
design may tend to make the system highly inflexible and limit the evolution of the
34
system. The system should support the ability to "snap-in" new toolsfor design
and analysis as the system evolves.
*
Distance Collaborative Support vs. Flexible System
For teams to be able to effectively collaborate at a distance a mix of
communication, and distributeddesign and analysis tools are needed. If these
tools are not integratedwell they may be of little usefulness. Whereas integrating
these components into a useable sub-system may tent to limit the flexibility of the
system.
*
Distance Collaborative Support vs. Operate on Any Platform
Distance collaborativetools will need to operate on an inhomogeneous mix of at
least three majorplatforms. Selection and integrationof tools to support
distributedteams that are truly platform independent may not be possible.
These conflicts need to be managed and considered as the design progresses and any
systems that are built for the system should either support multi-platform use or
utilize a client -server architecture. Design and analysis tools should utilize a
standard application interface for tool integration.
35
6.3
Use Case Diagrams
Use Case Diagrams helped identify the need for an external user interface that would
determine levels of access privileges assigned to each external user, and to provide
services based on those privileges. A Use Case Diagram for DE-ICE is shown in Figure
6.3-1 and a "design" Use Case is shown in Figure 6.3-2. Use Case analysis showed that
there would be four main actors interacting with the system faculty/TAs, students, staff
and external users. Creating the Use Case diagram also showed that some of the DE-ICE
functionality extended beyond the system boundary. Use Cases for the faculty show the
main expected interaction with DE-ICE, but they should be able to use any functions of
the system.
Wind tunnel
Manufacturing lab
Figure 6.3-1 System Use Case Diagram
36
The design Use Case was evaluated separately because the functions can be used
separately or through an integrated instance from the "perform design work" function.
Figure 6.3-2 Design Use Case Diagram
The "manage data" function is shown as being able to be accomplished by students and
or a computer. This may put an unnecessary requirement on the users but it was felt to be
advantageous to give users the freedom to manage their own data if they so choose.
37
7. ArchitecturalSynthesis
The highest ranked TR's and their importance weightings were used in the QFD Product
Matrix.
Both were placed in the Product Matrix on the left side and multiple
implementations were created along the top to satisfy each TR. Use of the product matrix
enabled the team to quickly synthesize architectural concepts for the system while
maintaining traceability to the user needs. Another relationship matrix was used in the
body of the Product Matrix as defined in Section 4 and will not be repeated here. Total
importance rankings were used to compare the baseline architecture to the variants
generated by each team member. This gave a rough indication of the possible "overall
The Product Matrix may be seen in Figure 7-1 through 7-5.
relative" improvement.
Architectural implementations are grouped by functionality and a bold typeface indicates
a hardware-based implementation. Individual and groups of implementations considered
for prototyping are highlighted in the top of the Product Matrix.
Development of the Product Matrix occurred in an iterative fashion. Each time the team
met to discuss their concepts, new items "bubbled-up" and were added to the Product
Matrix.
Below the Product Matrix is a section where the architectural variants were analyzed.
When an implementation was selected for a particular architecture, its score from the
relationship matrix was carried down into this section allowing the team to evaluate the
percent improvement of each concept relative to the baseline. This may be seen in Table
7-1.
Architectural Variant Total Score Percent Improvement
A
165405
61.4%
B
81703
21.9%
C
120136
46.9%
Baseline
63781
0.0%
ABC'
116886
45.4%
Table 7-1 Product Matrix Architectural Evaluation
38
I
I
I
9
0
Technical Requirements
Design and analysis support
Provide guidance thoughout design process
Planning and management of design process
Experimentation support
Operate on any plaform
Distance collaborative support
Flexible system
Presentation and reporting support
Design priorities
TR Importance Weigh
eaive eig
Architecture A
297
170
149
145
143
122
98
32
-
1
3
3
3
3
3
3
1
1
756
8
l
512
11
Xi
496
11
I
1X
Architecture________
ArhtcueB7561
Baseline Architecture
Architecture ABC'
____________756_____________
3
3
3
1
3
1
1
1
3
9
3
3
1
9
3
3
3
3
3
9
3
9
1
1
3
3
*
1______________
756 1
Architecture C
Simulation Tools
Simulation Tools
Print~r~
Drintare
II
5~v~ta~m~
OnArs~tinn quntamc
fnarntinn
II
660
9
XI
1424
4
1100
5
2571
3
X lxiX_ Xi lx
X
1 11830 1 14241 11001 2571 1
XI
I
1
I
X~~.1
XEX
830
7
1
496 1 660
[
1616
4
I
X
116161
X I
___IT
____
I
X
__
9
9
1
9
1
1
1
1
1
1
1
*
*
*
*
1546
4
5277
2
2816
2
2771
2
3068
2
2850
2
2816
2
I___ I*
X ![
I
8301J5711
1
9
*
X__
I__
L
3
9
9
*
xI
XI
152771
I
257
x10
xX__
9
*
X1027
1 14241
9
7
1 5277
x
x
xX
IX
12771130681
1i
I
I1
1
1
1
III
__IX
I
I X1
1
I1 I
1527
1
1
I
1
Figure 7-1 DE-ICE QFD Product Matrix Page 1
39
Modeling & Model Management Tools
Math Tools
Discipline-Specific Design Tools
I\'9
-Z
3
1
3
1
1
3
9
1
1
9
9
3
3
1
891
7
3
3
1111
5
297
19
806
7
__x_
xX
3
3
9
9
1
9
3
1
3
1
1859
3
E
3
5352
1
I X
1 118591
F 1I
lx
1 x
53521
1034
6
I
1
x
9
9
9
9
3
1
1
1
1
1
3
I X [ _x
Ix
1
Ix
1
3091
2
x
13091
xiixi
__I__I__I__X__I__X
I
1
I
1
x
I
_
3663
I
3184
I
IXI
1 9231
3663
1
3369
IX
xi
Ii
1........L........L......
806 118591 53521 923 1
[
I
9
9
9
9
9
9
1
1
3
1
1
2771
2
3440
2
2771
2
9
1
1
2961
2
2961
2
2961
2
X I x
x
2961 296
11
2818
2
3992
2
x
x
xX I
12818
IX
1
1_1
Ix
Xx
2 77 1
]
13440
II
x
x)
344012771
1
x
x
Ix
x
x
129611 28181 39921 27711 28181 2771
-x[
111
Ix I-x I x[I_
3663130911 2961
2818
2
x_L _ J
3992
I x
129611
x
12961
2771
2
2818139921
Ilx- i ii
I--I ..._ I
2961 1
I
lxIx
1
9
1
1
3663
2
3184
2
12210
1 18591
x
3369
2
122101 33691
ii
(x[
J 806 118591
2210
3
I
806 '1859'
1
9
1
923
6
AC4jxO
C7
N
I_
[
x-39921
128181
I_ I
I
I
1I139912771j 1
I
1
1
x
12771
I x X
J344012771
Figure 7-2 DE-ICE QFD Product Matrix Page 2
40
Figure 7-3 DE-ICE QFD Product Matrix Page 3
41
Experimentation Support
Project management tools
Guidance
C cC3
c~
-~
Sq~Z,
Z'
I\N
613
91
1
1
1
9
1
9
3
1
1
9
9
9
9
1
2099
3530
2375
3
3 2
1714
4
370212873129661 196 840
112
2 12
1516134
4 14
J71
1
3h E
8E E
1732 1525
4435
2051 1305
2644
1337
5
3
1305
5
16021
4
1305
5
TI
I
1~ x72 x83 x 1
- I_
x I X
37021 28731 29661_ 196
531 2091372
3002
2
1511
4
1j56
x_
1_116_1_302
=
EE61 1
-02 172
lxx
1 300211732
1-
5161
xj
37021 28731
E
9
13
1
1
x
1 Ii
x
X Ix
287 74 27135301j 20991 3702 1 28731 29661
x
171
1~~ 1
50
xl
I 350
I2I7I1275 531
9
911
3
2817
2
3
1
1
9 1 19
9
9
9
16
1
9
2
c-
9_'V
9__99
1
c4
-
e~
511
I -
I
1 1
02
15251
lxx
1525 120
J05
__
1
1
126441
xI
1
I___ I I IX I
.1
17311525 1
110
J
I
J
30021 17321 15251
1
X
i-_
-x
11525j
x
1
- - 1 H
~732
1602
X__ I I
-
110
j
X....
-
~
1
9
Z162
Figure 7-4 DE-ICE QFD Product Matrix Page 4
42
Remote Presence
Cross Platform Communication
0
00
11b,
1C
1q1
3
3
3
3
1
3
9
3
1
1
_1
1
9
1
3
9
9
9
1
9
1
1
9
1
1
1
9
3
3
9
1
9
31
1
1424
1130
755
755
755
1804
2535
1783
1371
1228
2039
645
755
755
7
1804
2535
1783
1371
1228
2039
645
755
755
2535
X
1
~ 1371
~
1755
xl~
[12281
x
_
1
9
1
9
9
1
3
1
3
3
3
3
9
3
1
1
1_1
9
3
3
1228
1751 1751
803
1979
2775
1196
660
366
1484
1377
2385
1228
1751
803
1979
2775
1196
660
1
1
jxj_[__
1
1377
1
11
1783
6451
3
1424
_
x X
_
2385
11228751
I X1
[x
x
1228
I
X
1j
803 I 19791
X
I X
x I xX lxi
1751
[X
12281 17511
1
11424
171
_6
11377
12385 112281 1751 1
x32I27lli
1751
803
__
1
462
111961
9
1
3
756
3227
756
3227
7
3227
x X
_
1
1 756
X
_I_
_I_
1
4
X
x__~_
19791
3
3
3
3
3
3
3
2385
X
1121 231 645
9
3
1377
645
_5
9
9
1
9
1484
XX
1
75[ 1 1804 2551181
9
19
1645
X_ I 1424
XJ
I
x
3
366
S2535
1804
4
1p
01
11979
19791
1
1 160
li
J
3227
17132
J751
Figure 7-5 DE-ICE QFD Product Matrix Page 5
43
rresetiiaiionineporiin~
IPresentationepotig
I
Flexible
System
Flexible System
0
00
0OA0
1
1
340
91
1
1
1
1
1
83
-
111
9
9
3
3
9
3
9
3
9
9
9
1
1545
1392
5
4i
4
1990* 1-45- 1392
x
1424
........ 1
13 I- 1392
4
4
x
ii
x1
Ii
1392 13921109811098 1751
142
4
14
109
10815
5
2483
1036
803
1673
3
6
7
4
5.4
I
I
I
xxIx
x
x
10361 803
1 124831
X~14
X~
=55 =
155 1
14
j 1424
1
1
1
1
1
J
4831 1
X..4....... I
1 1J 43
9
3
9
1
9
1
1
1250
3
3
1
9
1680
4
Ix
I
9
3
9
3
9
978
1275
6
882
7
1x Ix
lxx
x____
116731 16801 978
4
9
3
1
3
1
3
3
3
857
1778
194
4+
3
1
1
1
9
9
36
U
14
x
x
Ix
826
I
7
I
*
1
9
9
529
11I
249
280
171
147
1683
A
x x Voalsco% improv
x I x I x 11ticEINipo
I x
Ixxj
16731 16801j 978 1j1751
38
197
17781
85
1
127
I
Ix
1
1
9
199
9
1
3
3
3
9
9
3
x I_ x
X
x
1
x I I X XI XI
0 63 60 7 25
1
117781
X
857
xI x
I
117781 1974 1
826 1529 11683117503511.93955
1
~tasoj/I
1I
scl -01
xIXI I
1J 678~j1.1 50
1 1826 1 529 1
Ix
I
1 826J 529f 1
x
Tota scor %improv
1861543
Figure 7-6 DE-ICE QFD Product Matrix Page 6
44
7.1
Concept Development
To develop architectures, each team member used the Product Matrix to identify
implementation combinations that were felt to produce "good" architectures. Each team
member generated conceptual drawings to convey the key features of the different
architectures. Interestingly, team members initially used a different "view" to describe
their architectures.
There was a physical, software/IT, and equipment Block diagram
(EBD) and each one conveyed different information. It was realized that to fully describe
the concepts all three views were needed (discussion, Boppe 3/15/2000). Figures 7.1-1
through 7.3-3 show the Software/IT, EBD, and the physical views respectively for the
author's architecture "A." Architectures "B" and "C" can be seen in Appendix E.
After development of the architecture consideration was given to the design principles
used that affected the concepts. Design principles [22] used sought to:
" Minimize the effect of the varying clock speeds of the student team members
" Maximize communication and design flexibility
" Maximize the useful life of the system
Software/IT Conceptual View:
The software and information technology (IT) view depicts the nested IT infrastructure
developed to support users working on a distributed laptop computing system within the
design room, the department and outside of the MIT physical boundaries. External users
may gain access to the design room server through a user authentication application (i.e.
AltaVista Tunnel or Tether), the DOME server, log onto the video bridge to receive
streaming audio/video over the World Wide Web, or onto individual user laptops through
NetMeeting or Virtual Network Computing (VNC). Users within the physical confines
of the MIT network will have the same access options but will be able to gain direct
access to the design room server and labs outside of the design room.
45
External Users:
Students
Faculty
Lecturers
Customers
Vendors
Extemal Users
Laptops:
Windows 2000 Workstation
Matlab
MS Office
Working Model
VenSim
Pro E
AutoCAD
VNC
CVV/NetMeeting
Instant Messaging
Group E-mail
ePost it notes
Software Through Pics
STK
Maple
Compilers
NASTRAN
Risk AnalysisVirtual WorkBench
PSM32
LabView
QFD-Capture
Latex
Visio Technical
Sample Design Processes
Fax Software
TRIZ Tools
MasterCam
Front Page
Stat-Ease
CFD
Figure 7.1-1 Software and IT Architectural View for the Author's Architecture "A"
46
A DOME server would be installed on the Aeronautics and Astronautics Department
servers which allows students and faculty users to access the integrated modeling
environment over the WWW. DOME will be used to integrate sub-system models and
costs that will allow the team to analyze and optimize the system globally. All software
needed for the student designs would be installed on the server and on each laptop; a set
of CDs should also be provided to each student using the system that contains all the
needed software.
An automated software installation server will act as a means of
software distribution that will enable students to install any applications not currently on
their systems. Software selected for architecture "A" contains all possible applications
that students could use in support of the life cycle of a design project, based on the
authors experience and the survey data collected.
Software grouped by class and the
recommendations for additional packages are listed in Appendix K.
Team communication is designed to support different modes (i.e. person-to-person,
person-to-group, group-to-group, and inter-group) is provided by NetMeeting, VNC,
telephones at each workstation, fax software on each computer, ViewStation FX, and
group emails in this concept.
A second eighteen-inch LCD monitor will provide additional audiovisual support with a
PC camera at each workstation to be used for communication and design work within the
room. View Station FX and a video bridge will provide support for the integration of PC
camera systems, PBX and IP video conferencing systems.
This will also provide the
capability to transmit streaming audiovisual over the Internet. Video conferencing will
be enhanced through the use of novel components called the Electronic White Board
(EWB) and the Round Table Virtual Presence (RTVP) system. Descriptions of the EWB
and RTVP can be found in the prototype section.
Dashed lines indicate possible concepts for prototyping and will be discussed in the
prototype section.
47
Equipment BlockDiagram View:
The EBD shows the components, their interfaces, and the types of interfaces specified.
Laptops are selected over workstations in architecture "A" to provide the following
benefits:
e
Remove the constraint of students needing to perform all design work in the
design center
e
Flexibility of the users to work and form groups anywhere is maximized
e
Frequency of communication between team members can be increased
e
Round table meetings and ICE sessions are easily facilitated using laptops at the
conference table
Architecture "A" utilizes wireless Ethernet cards in all the laptops to facilitate team
flexibility and ease of reconfiguring the design lab. Due to the limited throughput of
wireless Ethernet systems, it is required to reduce the traffic over the net in the design
lab. This can be accomplished if all user applications are installed on each laptop (as
described in section 11-1) and the network is used for communication and data exchange
only. A 100 Mbps Ethernet raceway will also run around the perimeter of the room so
that students can hardwire into the system to increase network speeds.
Laptops and
cameras should also be provided to each faculty member using the system to enable
sharing of data and communication tools. Tether should be supplied to all users free of
cost so that users can work at home with out penalty.
Color laser copiers, a digital
networked copy machine, a scanner, and a large format plotter will further enhance team
communication.
48
Video Projector
Overhead Projector
KEY:
Phone/computer cable
V
deo Recorder
Wireless Comm Link
--.-
UUUU
Rapid Prototyping
Vd
Video ridge
View Station FX
Video
Video Projector
-
100 base Ethernet
Scanner
PC Video
Wind tunnel
Internal Data Flow
-- -- -- --
Digital Copy Machine
Moitor
Faculty/TAs
Manufacturing Lab
PC Video
Other Labs
:Oather
LLaptop
Disk storage
C
--
Tel
IT!
hone
Monitor
Server
Win 2000Server
Dome
ProE SharedDatabase
VNC
Office
View Station Software
Personal Folders for Students
Shared Foldersfor Work
Auto InstallationSoftware Package
Cost Database
TetherMS
Tether
Athenal
l iOn-Line
ii
Sun
Laptops:
Windows2000 Workstation
Server:
Color Laser printer
Laserprinter
Lsrpitr
Laser
printer
Help
Ineatve IEEEStandards
16.870 SearchableNotes
GroupBrain Storming Tools
Star trek Vileo Terminal
ARC
S
e
Matlab
MS Office
Working Model
VenSim
Pro E
AutoCAD
STK
Nastran
Risk Analysis
PSM32
QFD-Capture
Visio Technical
Processes
TRIZToods
MasterCam
Front Page
Stat-Ease
CFD
VNC
CVV/NetMeeting
Instant Messaging
GroupE-mail
ePost it notes
Software Through Pics
Maple
Compilers
VirtualWorkBench
LabView
Latex
SampleDesign
Fax Softare
Plotter
In
PP e
PC Video
Monitor
PCommand
PC Video,
Laptopcomputer
PC Video
Telephone
Telephone
Monitor
Laptop computer Telephone
Monitor
Laptop computer
Telephone
Monitor
Laptopcomputer
Figure 7.1-2 Equipment Architecture View for the Author's Architecture "A"
49
Physical View:
The physical layout of the main design center area and the team rooms is shown in Figure
7.1-3. Rolling desks are used on three sides of the room, with the front of the room used
for whiteboards, printers, supplies, and the video screens.
Three video screens are
arranged to partially surround the meeting Table to enhance natural communication
during meetings. Three video projectors are permanently mounted in the ceiling and are
pre-focused. Video screen display is controlled through Meeting Suite 5000. This would
allow software control of the screen displays. The RTVPs have been placed to minimize
intrusion into line-of-sight discussions at the conference table while at the same time
enabling the local and remote team member to feel that they are in a normal face-to-face
meeting.
50
PBX
Video Bridge
AA Server
.2
gul-m
Figure 7.1-3 Physical Architectural View for the Author's Architecture "A"
51
7.2
Concept Evaluation
Evaluation of the architectural
variants and development of the recommended
architecture was accomplished through the use of a Pugh matrix.
Only the author's
architecture will be discussed in this thesis; please see Manka and Nolet for discussions
of "B" and "C."
When evaluating alternate concepts against the baseline a +,
-,
S was awarded if an
increased, decreased, or similar performance was achieved respectively. The +, -, and S's
were then summed to indicate the relative ranking of each concept against all the
evaluation criteria (Pugh [5]).
The architectural baseline used for the Pugh Matrix was the current lab and the planned
updates for MIT's Building 33 and can be seen in Appendix B. Currently the physical
configuration includes rolling furniture with Pentium III workstations on each desk, with
a 100 Mbps Ethernet raceway around the room. NetMeeting will be used to share
applications and for display on two video screens.
A cornstarch Rapid Prototyping
machine will be linked to the lab along with other labs, faculty, and TAs. Cameras on
each PC or a video conferencing system are considered as an enhanced baseline version.
Software for the baseline architecture can be seen in appendix K under the column "Class
request."
Pugh Matrix scores for the author's architecture "A" were 4 pluses and two minuses this
can be seen in Table 7.2-1. Scores were determined by the preferred characteristics of
each concept. Architecture "A" incurred two minuses due to the judgment that it will be
much more expensive to implement and operate by supplying laptops vs. desktops, the
color laser jet printer, digital copier, secondary LCD monitors, and the large amount of
software recommended.
52
Architecture
Department
Baseline
Cost to
A
B
C Preferred Characteristics
-
-
-
Implement
Design
Functionality
E
+ s
E
_
_
_
_
_
_
_
_
_
_
_
_
_
A: innovative remote presence, many
+
Flexibility
+
+
Operational
oe
+A
+
S
_
_
+
+
evolution via DOME in A___
-
C
+
Functional
_
C: no dual monitors, laptops, wireless
network; common, off the shelf s/w
A & C: integrated subsystem models,
+ broad range of design tools, UV polymer
for experimentation, brainstorming and
40design
Communication
S
Baseline: simple
_
Department
Cost to Orate
ABC'
S
modes aval., A & B: individual mobility
A & B: wireless LAN, room
S reconfigurable, B: OS mix, A: DOME &
s/w distribution
& C: large systems, electronic
+ whiteboard, knowledge database
+
+
+
A, B & C: collaborative, distance learning
Y,
X:-
Laptops supplied to all students as
part of tuition, no maintenance or
EABC':
upgrade cost for laptops
Is
Table 7.2-1 Pugh Matrix
Design functionality would be enhanced mainly due to access to multiple software
packages, and DOME to integrate sub-system models.
DOME would also improve
designs by providing the capability to optimize designs using a genetic algorithm to
search for optimal solution.
A UV-resin rapid prototyping system can greatly expedite
the time from design to experimentation, especially for use in the low-speed wind tunnel.
Communication functionality will be improved by providing multiple methods of
interacting with team members. Laptops will allow mobility within the lab for teammates
to freely meet and discuss design ideas.
within or outside the lab.
Team members can work from any location
MS NetMeeting, and VNC
will provide access to
communication, team member's drawings, data, and information.
Flexibility is greatly increased in architecture "A" physically through the use of laptops
and wireless LAN, the RTVP and electronic whiteboard. PC video, ViewStation FXTM,
and MeetingSuite 5000TM (video bridge) build in communication and meeting flexibility,
53
allowing conferencing at three levels: person-to-person, person-to-group, and group-togroup. Software flexibility is enabled through the large suite of tools that will support the
life cycle of the design process. Additionally, students would have the choice of software
tools to use during any phase.
Operational modes would be supported by the ability to design large complex systems
through sub-system integration in DOME, multiple modes of collaboration, distance
learning software, and integration of the knowledge database, on-line help, and access to
and management of the product development process.
Comparing the results of the Pugh analysis to the raw scores from Table 7-1 it can be
seen that the trends are similar, but the numerical raw scores over emphasize the "better
qualities" of the three architectures while completely ignoring the costs involved. Thus
the Pugh analysis has captured the true ranking of the systems.
54
7.3
Baseline System Architecture
ABC' was selected as the final architecture for the DE-ICE system. Overall score on the
Pugh Matrix is four pluses, one same, and one minus.
functionality,
Design and communication
flexibility, and operational modes were still judged as being an
improvement over the baseline architecture. Expected cost reductions in implementation
and operational would be accomplished by requiring students to supply and maintain
their own laptops, removal of wireless networking, and reduction in the recommended
software. Student supplied laptops could be achieved by either the department supplying
them as part of a tuition increase or setting up an arrangement whereby the students can
purchase the laptops themselves at a reduced cost as in the IBM-campus solution [24].
The solution to the laptop cost concerns are can be justified when consideration is given
to the fact that most students entering MIT currently purchase a computer for their career
at the institute. This type of arrangement would remove the initial purchase and lifecycle
upgrade cost of the PC's for the lab. Lifecycle physical maintenance cost would be
reduced to just the servers, monitors, and the network. IT costs may increase with this
solution due to configuration conflicts and setup time, and there would also be the
possibly of a reduction in reliability due to students reconfiguring their own systems. A
benefit of this solution is that students carry away the older machines with outdated
performance and each new class of students would have current technology laptops for
their personal use.
Communication and collaboration functionality is slightly reduced due to the elimination
of the RTVP, electronic whiteboard, and the video-bridge. IP video conferencing will
also replace the View Station FX. Software applications and tools are reduced but DEICE should still provide more functionality than the baseline. On a raw score basis there
could be an improvement of 45% relative to the baseline if ABC' was implemented.
ABC' software/IT and equipment architectural views can be seen in Figures 7.3-1 and
7.3-2
55
I
External Users:
Students
Faculty
Lecturers
Customers
Venders
VNC
CVV/NetMeeting
Instant Messaging
Group E-mail
ePost it notes
Software Through Pics
Maple
Compilers
Virtual WorkBench
LabView
Latex
Sample Design Processes
Fax Software
Figure 7.3-1 Final DE-ICE SW/IT Architecture View
56
VideoProjector
KEY:
Phone/computer cable
VideoRecorder
Video
ViewStationIP
100 base Ethernet
VideoProjector
Internal Data Flow
Server
VNC
Win 2000Server
Dome
ProESharedDatabase
VNC
MSOffice
ViewStationSoftware
PersonalFoldersfor Students
SharedFoldersfor Work
AutoInstallationSoftwarePackage
CostDatabase
On-LineHelp
InteractiveIEEEStandards
16.870 SearchableNotes
GroupBrainStormingTools
KnowledgeDatabase
CVV/NetMeeting
InstantMessaging
GroupE-mail
ePostit notes
Software
ThroughPics
Maple
Compilers
VirtualWorkBench
LabView
Latex
SampleDesign
Fax Softare
I
Sun I
il
Internet
Monitor
Laptopcomputer
Telephone
Telephone
Monitor
Telephone
Laptopcomrputer
Moentor
Laptopcomputer
Monitor
Laptopcomputer
Figure 7.3-2 Final DE-ICE Equipment Architecture View
57
7.4
Baseline Product Development Process (PDP)
For the undergraduate classes targeted, the recommended PDP is Ulrich and Eppinger
(UE). UE consists of structured methodologies that explicitly define the decision process
[8]. It is a relatively simple PDP that is appropriate for less complex consumer-based
products. Since most of the undergraduates will most likely lack experience in CDIO it
should give the students a good general reference PDP that can expanded upon for a
particular design class or project. Using this process should help the students to plan,
manage, coordinate, and improve the quality of the designs. Additionally, professor Blair
is currently planning on using the UE PDP in several of his classes.
For conceptual design classes at the graduate level students should have access to the
NASA systems engineering process or IEEE 1220. These processes offer a very detailed
and thorough break down of the systems engineering process and should be useful for a
wide variety of design projects. They will provide a solid framework that the students
can tailor to their needs.
58
8. Prototype Development and Demonstration
The second phase of the design project was to identify and prototype an enabling subsystem of the DE-ICE system.
During the synthesis of the author's architecture a
constant vigil was maintained to capture or combine novel ideas that arose in discussions
and weekly team meetings that would lead to possible prototype concepts. Four concepts
emerged from the author's architecture "A" and are as follows along with a short
description of each one:
1. Round Table Virtual Presence (RTVP)
2. Electronic whiteboard
3. On-Line Teaching Assistant (OLTA)
4. Distance Learning Software
RTVP
is
designed
to
promote
natural
conferencing/collaboration by remote presence.
team
communication
for
The system should have automatic
audio/video tracking of a speaker to maintain focus and picture quality.
It can be
integrated with the video-bridge and S/W video switching to select or move to a different
speaker. It should be able to be used with/without View Station FX and the video-bridge.
The units should be small and moveable for easy reconfiguration of the meeting room.
Please see Appendix I for an illustration of the RTVP.
The electronic whiteboard is a large-format image of any data/application from a
computer that allows multiple user interaction in a distributed environment. People in the
room can physically draw on the board, which captures the input and distributes the
information in real-time for communication and visualization for all team members.
Remote team members could draw on their computers and update the whiteboard. Notes,
comments, sketching on any applications data/drawing could be manipulated by all
teammates. The system should capture the interactive team decision process and events
while enhancing team brainstorming. Please see Appendix J for an illustration of this
concept. Systems currently exist that have some but not all of the functionality described
with costs of -$ 5000.00.
59
The OLTA is a graphic and interactive resource focused on the product development
process. It would link relevant course notes, sample PDP, SEMP, acquired and retained
knowledge from past projects, library resources, etc. The system should automate the
capture of objects from student designs into a knowledge database to add value to current
and future users of the system. Users will have the ability to tailor DE-ICE resources to
their specific needs. There is also the possibility that the OLTA can act as a de-facto
project management system with deliverables time-phased into system by the faculty. In
the future there is also the possibility of automatically linking student work that is
delivered in to the system by integrating it with DOME. Student work entities can also
be used as measurable outcomes for grading and accreditation support to the faculty.
Faculty members also have the prerogative to make outstanding examples available to the
user base, thereby increasing the value of the system. This concept can be seen in Figure
8-1 and will be discussed further below.
I
Requirement
Generation
Detail
Design
Time phased deliverables
drag and drop with auto-link
Test
Operation
IEEE, EIA 632 processes
Inputs and outputs
Theory
Examples
Relevant notes
Exiting objects in knowledge database
Library search
DE-ICE support for the item
Team members responsible
Lessons learned
Patent search
0
Cretsuetwr
Current student work
Past student work
i.e.
DE-ICE QFD
DE-ICE PDR & ADR slides
QFD-Capture
MS Excel
DOORS
RDD-100
Etc.
Figure 8-1 OLTA Vision
60
Distance learning software is a web-based interactive application that will allow class
delivery to remote students.
By using integrated audio, video, and a standard set of
application a system would be created that would improve on the existing systems [33].
Prototype Selection:
Prototype concepts were evaluated against the TRs in a decision matrix as shown in
Table 8-1. All of the prototype concepts could improve the educational experience of the
students. The decision matrix assured that the selected concept would meets the needs
initially defined by the Aeronautics and Astronautics Department and therefore should
improve active learning, and build on the CDIO philosophy.
Prototype Concpets
.4,
Technical Requirements
&K>
Q~Z
Design and analysis support
Provide guidance thoughout design process
Planning and management of design process
Experimentation support
Operate on any platform
Distance collaborative support
Flexible system
Presentation and reporting support
Design priorities
TR Importance Weight
Helative weignt (/)
297
170
149
145
143
122
98
32
1
9
9
3
1
9
9
1
9
9
9
3
1
9
1
1
1
2711
3
3068
3
6334
1
(~ ,4,9
9
3
9
1
2567
3
Table 8-1 Prototype Evaluation Matrix
Ranking against the driving TRs shows that while the RTVP, electronic whiteboard, and
distance learning software are very important for team collaboration and system
flexibility they do not address the highest priorities of the system. The OLTA not only
received the highest score but also ranked very highly against the most important TRs.
This proved that the OLTA would be the concept to focus on for the remainder of the
project.
61
An On-Line TA (OLTA) is felt to be a key to DE-ICE improving engineering education
by providing guidance to student users that may lack extensive industry background and
would facilitate the transfer of knowledge in developing products from the faculty to
students. It will help students gain information on what, when, and how to accomplish
design goals and on how DE-ICE can support their project.
As further evidence that the team had determined a valuable prototype concept, during
the architectural design review Dr. Sercel stated, "The OLTA could revolutionize
engineering education as we know it."
Additionally, during the final design review
Professor Crawley felt that while there are currently systems available that perform many
of the functions outlined in the OLTA none have integrated them into a system focusing
on product development methodologies.
62
On-Line Teaching Assistant:
The OLTA concept is composed of two major components: a web-based front-end for a
user interface and a front-end for OLTA authoring. As discussed during a conversation
with Dr. Blair on (4/6/00) the key to the success of the OLTA is that the system is easy
and fast for faculty to create and/or customize to their specific needs. Additionally the
system should be simple and fun for all users.
Also, as pointed out by Professor
Hansman the design of the faculty interface should be fully explored to assure that
usability issues are addressed.
Loading time for the OLTA should be as fast as possible
with only updating changes made from the authoring tools at each new login session. To
minimize OLTA loading time which may be increased by congestion from multiple users
logging into the system, mirror sites may need to be considered.
The main functionality for the OLTA is broken down below for the student user front-end
and the authoring tool.
1. Front-end student user interface.
The user interface will be a graphic web-based (platform and OS independent)
application that will integrate access to:
i. A general Product Development Process (i.e. IEEE 1220, EIA 632, Ulrich
and Eppinger), for the prototype Ulrich and Eppinger will be used
ii. Capability for students to create and analyze (DSM, PERT) their own PDP
for a class/project
iii. OLTA/DE-ICE help
iv. Access to live faculty and TA's
v. Give feedback on the DE-ICE system/OLTA/classes
vi. Utilize advanced search tools to gather information from multiple
resources (i.e. patent searches, knowledge database, lessons learned,
course notes, SEMP...)
vii. Access the supporting tools in the DE-ICE system
viii. Identification of class materials that contain deliverables and timing
63
ix. Submitting class deliverables through the OLTA
x. Attending electronic classes and lectures
Students who log onto the system will be allowed full access to all resources on
the DE-ICE system. Guests should have logon capability and could utilize some
of the functionality of the system. The logon process can be used to:
xi. Generate the class customized PDP for a particular user
xii. Automatically update only the changed information from the authoring
tools
xiii. Collect user information and access time/date
xiv. Object tagging
xv. Capture of objects
xvi. Gathering electronic class attendance information
xvii. Collection of OLTA/DE-ICE usage information
2. Front-end authoring tool for creation/customization of the OLTA.
Because the OLTA will quickly become a very complex network of web pages
and custom scripts an authoring tool is needed to reduce the time requirement
placed on the faculty when creating/tailoring the OLTA for a specific class. The
authoring tool needs to perform the following:
a. Define a top-level PDP for the class
b. Customize the existing top-level PDP
c. Highlight PDP phase tasks that contain deliverables
d. Lay out deliverables schedule
e. Define PDP in phase tasks
f.
Insert content to be displayed for top-level and in phase tasks
g. Define class goals and objectives
h. Insert class syllabus
i. Define class notes
64
j. Plug-in new tools for class use
k. Build the customized OLTA web-pages
1. Automatically verify page links and view page layouts as a thumb-nail
m. Automatically record when changes are made to update OLTA
The goal for the time required of the faculty to interface with the authoring tool
should be less than 1/10 normal class preparation time, not including preparation
of the actual content.
Figure 8-2 shows a Use Case Diagram of the expected interactions between the users and
the OLTA, and Figure 8-3 shows a graphic representation of the relationship of the
authoring tool to the OLTA and possible interactions in the OLTA.
Figure 8-2 OLTA Use Case Diagram
65
Prelminarv Design
MissionStatement
Productdesenption
Define
uddyou
Preimiarydesgn
Identifycustomerneeds
Concept
Development
Needthi
.tQ!bis
NeedJthis
.tQthis
2
a
EstablishTaret Soecifications
Identifvcustomer INed
Establish
TaroetSoecilications
AnalyzeCompetitive
Products
Contact Professor
ContactDTApe
MissionStatement
feedback
\eGive
Product dgsc'Nsto
Define
Identit
coals
Outputs
Inputs
Include
Tasks
nejarket
-Search
agls
AA 16.00-
samma
dataaeDslasrhv
Patent search
------- -
D isplay A rc- hive
-
~database---
Knowledg
DE -1:Preliminary
design]
arse Notes
Sea68
-------------------------D
n
etc
Class Deliverable?
Product description
-
Dynamic HTML
Mission
S tatement
VBA scripts
g
A
Product
Description
Databas e with VBA
scripts
Figure 8-3 OLTA Interface Relationship Diagram
66
Prototype Work Break Down:
After the decision was made to pursue the OLTA the team divided the major tasks and
made a first cut at the functionality that would be needed in each task. The tasks were
then prioritized for the prototype development. Task packages were analyzed by each
team member to decide what reasonable performance could be demonstrated in the
prototype. This may be seen in Table 8-1 which contains the team member assigned to a
task, task priority for the prototype, task name, top-level description of the functionality,
and the aspects that will be demonstrated in the prototype.
The team then began looking into options of support for the individual tasks; resources
that were identified were Mr. David Mitchell from Microsoft, and Mr. Jay Pilkington
from Wertheim Associates.
Meetings and discussions with these resources proved to be very informative. After a
meeting with Mr. Mitchell to describe the OLTA concept and functionality, Microsoft
Site Server was suggested as a potential environment in which to create the OLTA. Mr.
Mitchell also suggested that the best use of the prototyping phase would be for the team
to define the logic and basic structure of the design and to show a mock-up of the OLTA
for the final design review.
67
Team
member
Bruce
Priority
Task
Functionality
Demonstration of
performance
1
2
OLTA authoring
tool (OLTA-AT)
Database with form to input PDP and content that will drive OLTA
web-pages, define links to faculty and TAs, assign class
deliverables, input class specific tools
Design display forms,
OLTA front end
User interface driven by OLTA-TA, integrating all functions
Hardwired web-pages to
described in section 16.1 items i-x
show concept, modifiable
content on a few pages
database categories,
nput and eb-bui how
from TA
3
Alex
1
2
Build your PDP
Search OLTA
Object capture,
Display tasks as hierarchical list indexed under top-level PDP,
display task inputs and outputs, enable task selection by user, link to
DSM with inputs from user selection
of tasks, input to DSM
Integration of advanced search capability seeded from OLTA
Search prompt, FFD,
current task, search criteria user modifiable, capability to define
search objects
Example search results,
Object tagging, object capture, knowledge database structure
Tags, file structure, student
requirements, FFD
knowledge database
Simon
Display PDP database
w/inputs outputs, selection
3
1
Design tools
Submit class
deliverables
Testing evaluation and recommendations for design tool integration
Submission of class deliverables, interface to object tagging, input
to knowledge database, possible auto-link?
Undefined
2
DE-ICE support
Filtered list of tools available to support tasks at current point in
PDP
Show tools supported at
Simple short and long term plan to implement the DE-ICE system,
focus on long term development of OLTA
Document showing short
and long term plan as
3
Implementation
plan
Use case showing
functionality, FFD
different level of the
process, FFD
previously discussed
Table 8-1 Prototype Work Package Descriptions and Break Down
68
Prototype Functionality:
Top-level functionality for the OLTA can be seen in Figure 8-4 which was derived from
Table 8-1.
Each functional block is further broken down and can be seen below for
Blocks 3, 4, 5, 9, 11, and 12 or see Manka [30] for Blocks 6 and 100.1 and Nolet [31] for
1, 2, 7, and 8.
Studffguest
Faculty/fA
Figure 8-4 Top-Level OLTA FFD
A session with the OLTA starts when a user (student or faculty) logs-on to the system.
Web pages are initialized and personalized in Block 12.0
Personalization was achieved through the uses of Active User Objects (AUO) in the
prototype, which will allow accessing information from the membership database.
Typically this would be student or faculty, class number, preferences, permission levels,
69
etc.
User permissions are determined from the personalization function (Block 2.0).
Permissions govern classes the user will have read/write access to for the class PDP,
homework review, and grading. An option list (Block 1) presents a list of classes to
choose from and what type of work is to be done.
When a faculty member or TA logs-on, the authoring tool page is displayed (Block 3.0).
The faculty user has the option to review and grade homework and edit the PDP or
content. When a student logs-on, the OLTA page is customized for his/her class and will
be displayed (Block 4.0) with links to Blocks 5-11.
70
FFD for Blocks 3, 4, 5, 9, 11, and 12
The authoring tool is where the PDP for a class can be selected, edited and updated.
Homework and class deliverables can be scheduled. Class notes, goals and syllabi can
also be updated or input. Functional flow of the authoring tool is shown in Figure 8-5.
Provider Uploads, edits or
deletes content via interface
and submits update
Provider sets a content type
and applies attributes relative
to this type and submits
jo
document
31*3.1.*1
---
Editor modifies document
properties, as appropriate, and
---if necessary, approves
content, which is then
submitted
3 .. *
Site administrator submits site
content to stage server for
review
3.1.*
Figure 8-5 FFD for Blocks 3
The main student interface to the OLTA, Figure 8-6, will allow users to give feedback,
browse the class defined PDP, access on-line help for the DE-ICE and OLTA system,
attend e-classes, check deliverables schedules, or access class-specific notes.
71
Give Feedback
4.1
Browse PDP
4.2
On-line help
OLTA
4.04.
Attend e-class
4.4
Check HW
schedule
4.5
Access class notes
/syllabi
4.6
Figure 8-6 FFD for Block 4
Faculty members or TAs with the correct permissions can access all class homework
submitted through the OLTA, Figure 8-7. The capabilities to open, review, and add
comments to or corrections in the submitted materials are contained in Blocks 9.1 and
9.2.
Interoperability between PC and MAC operating systems software may pose a
significant problem in Block 9.1 and should be further considered. Grades are assigned
and posted to the system. Selections of exemplary work are flagged for public access to
increase the value to current and future students searching the knowledge database.
Faculty comments made in during grading should also be made publicly available so that
students can understand the value in the examples.
72
Figure 8-7 FFD for Blocks 9
Authorized users will also have the capability to modify previously assigned grades and
add comments as to why it was changed, Blocks 9.5 and 9.6.
Personal PDP, Block 11.0 Figure 8-8, is probably one of the most interesting features of
the OLTA. It is where students have the control over the PDP they could develop and
use for a class.
A listing (Block 11.1) is displayed that would contain all the PDPs
contained in the knowledge database (i.e. IEEE-1220, EIA-632, class-specific PDP, etc).
When a student makes a selection it is used as a baseline to refine and alter to suit their
project (Block 11.2). The OLTA will then generate a hierarchical listing of the top-level
PDP phases with all the in-phase tasks listed along with their needed inputs and outputs
(Blocks 11.3-6) and a region to select tasks that the user thinks need to be performed
during their project. Students also have the capability to add and define new in-phase
tasks for a project. This will allow students to define the methodology they will use to
complete a design phase. After the tasks are selected a file is written to interface with the
DSM program which will be used for process optimization (Blocks 11.7-11).
Output
from the DSM optimization is then stored for the personal PDP of the user and could be
used to drive the OLTA.
73
Figure 8-8 FFD for Block 11
74
Preliminary Design of OL TA User Interface:
Initially the user interfaces were arranged in frames so that all of the functionality of the
OLTA was accessible on one screen partitioned into three sections.
The homework
section on the top, contact information and top-level PDP definition on the left, and the
main section for the creation of the PDP phase content. Figures 8-9 and -10 illustrate this
idea for the two user interfaces.
i
A_]
j4) D \My Documents\t web2\tramepagefacultyhtm
IVk &0 1
Contacts:
Enter Professor email
Select the Class to grade/Review Home Work
Class Number
1234"
Enter TA email:
Welcome: Professor Blair
Direct DE-ICE feedback to:
04/13/00
Edit Content:
Fred Donavan
Select Current Class
New
1|
Which Phases are covered in your class?
Input New Class
r
r
r
PDP Phase
Index:
(Concept Development
ISystem Level Design
Insert Class Notes
Detail Design
lTesting and Refnemen
Insert Class Syllabus:
Figure 8-9 OLTA Preliminary Faculty User Interface
After considering the frequency of use of the top and left frames and the reduction in
working area by having these sections dedicated to one task, it was decided to use a
navigation structure that would result in the users gaining more space in their interface.
Figure 8-10 illustrates the initial interface for the prototype that would be presented to a
75
I
student. The left frame would be likely to be less frequently used than the main PDP
interface.
Conjtact
:Hiurneuroik Deliver&d
[R-jud
lrae
jioeor
-msir-renf 2
......
F
FPoesDor -
PDP
WI
.__ _
_
.
.
.. ...
....
..
.........
..
.......
.....
..........
....
.... ..
....
..
...
I .
Brne Fru*.r Faliworth
rndev
BUMYour PDP
System Level Design
Search DE-ICE
ID customer Needs
Product Architecture
PrdcinH
apU
Figure 8-10 Preliminary Student Interface
76
....
3
..
OLTA Database Design for Web Content
Design of the OLTA prototype began with the design of the database which will store the
web content and deliverables. Content types are the categories of content that will be
used and submitted in the OLTA; these can be files of any type. Table 8-2 lists the
content types and their attributes, used for the prototype based on the author's estimate of
what would be needed. When the final system is developed the web content types will
likely contain additional items such as experimentation data etc and would need further
development.
Attributes are properties that are used to manage the content posted to the OLTA, to
define search criteria, and to build the knowledge database. When content is posted the
OLTA users are prompted to select the type of content they are submitting and then to fill
in any attributes that are associated with that type of content.
Attributes that can
automatically be captured by using the AUO are: class number, author, and submission
date.
Attributes:
9z
0n
E*E
X
X
X
X
X
X
X
PDP Phases
PDPTasks
Home Work
X
X
X
X
X
X
X
X
X
X
X
Notes
X
X
X
X
X
Syllabi
X
X
X
X
X
Grades
X
X
X
Reports
X
X
X
X
X
X
X
X
Presentations
X
X
X
X
X
X
X
X
X
Project Plans
Requirements
Proposals
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Table 8-2 Content Type and Attributes
77
Content providers are the users of the system who will be creating the content. The
relationship of a provider and the type of content that can be created by the provider is
shown in Table 8-3. An "S" indicates that the user will be providing some of the content
for a specific class or project. For example a student user will be providing their own
homework, reports, presentations, etc. for a class, whereas a faculty member would have
the authority to provide all of the content for the class PDP if they choose.
Content Type: A = All S= Some
encuty_
TAs
S
S
S_
S
S
_ _S_
S
_S _ S
S
S
S
S
S
S
S
Table 8-3 Content Providers
Content consumers are the system users viewing and using the content. Most users of the
system will have the ability to use all of the content provided with the notable exception
of homework and grades which is restricted to the faculty and the originators of the work.
Again an "S" means that content such as homework grades can only be viewed by an
authorized user for a particular class or by the originator (i.e. the student who submitted
the work). An exception to this would be if a faculty or TA member decides to make
some student homework accessible to the public for high quality examples.
Content Type: *
permissions by faculty/TA
O:6
enculty_
TAs
0L
9L49
A
A
A
AS
S
A
A
A
S
Cu
A
A
A
A
A
A
A
A
A
A
78
Students
Guests
SysAdmin
A
A
A
A
A
A
S*
S*
A
A
A
A
A
A
S
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Table 8-4 Content Consumers
Access control is determined by merging Tables 8-4 and -3 and defines the privileges to
read and write content into the system and is shown in Table 8-5.
permissions to pe sonal work/projects/casses
Content Type:
9
94 4
Faculty
TAs
SysAdmin
Students
Guests
RW*
RW*
R
R
R
RW*
RW*
R
R
R
R*
RW*
RW*
R*
RW*
RW*
R
R
R
RW*
RW*
R
R
R
RW*
RW*
R*
94
9:6o
o
R
R
R
RW*
R
RW* RW* RW* RW* RW*
R
R
R
R
RW
RW* RW* RW* RW* RW*
R
R
R
R
R
Table 8-5 Access Control
79
Prototype Development:
An iterated Use Case Diagram that highlights prototype functionality is presented in
Access DE-ICE support incorporates the "work manager" and "project
navigator" concepts developed by Nolet and Manka respectively. It is shown with a
Figure 8-11.
shadow due to the simulated nature of these prototypes.
Figure 8-11 OLTA Prototype Development Use Case
The author's responsibility for the OLTA development included:
1. Design of the display forms, database categories, database
2. Show content input and web-build functionalities
3. Hardwiring of a web page to show the interface concept with modifiable content
on a few pages
4. Displaying the output from the PDP database w/input and output relationships
5. Allow for the selection of tasks
80
6. Input into a DSM tool
MS Site Server was selected as the development environment. Site Server was selected
because it integrates many of the functions needed to develop the OLTA. Logon services
are integrated with Windows NT authentication which can then be used to personalize the
web using a COM interface. Using NT authentication means that individual student
accounts need not be created for students since they will already have accounts for their
work in the design center. This will reduce administration costs and centralize access
control to the system.
Tight integration with MS SQL allowed the use of a relational database to store, query
and retrieve all of the content for the web site and the knowledge database. Queries of
the database are performed using rule files that can be edited without using the native
SQL language. Content Management is a very useful feature of Site Server and builds-in
the approval functionality needed for homework that faculty member's would like to
make public.
Capitalizing on the personalization and membership functionality allowed the two user
interfaces to be integrated to a single web interface that is personalized depending on the
user. Reducing the number of elements in the system should reduce the development and
maintenance time and cost of the system.
Web construction is achieved using the COM interface to determine the user type and
name. Class number selection integrates into the rule files to query the SQL database and
return the content targeted for a user. Ordering of the content for the phase and tasks is
implemented using the reference ID attribute.
81
http:// 8.116.0.92/onlineta/defeult.asp
L
brucef to the On-Line TA
SWelcome
Search OLTA
Below isan example of a class PDP.
Build Your PDP
DE ICE Feedback
, 3'
A DE-ICE Support
Phase Outputs to:i System Level Design4
.....
A
2
Homework
1 (n) vphase
W is the tO
this is were all the work is done
syal-ft
gp
done
d
this is were all the systeis work
reurkngter
i
Phase 0Otputs to: Detail Design
Figure 8-12 OLTA User Interface
sc
renasoiegoehtcotnryei
ipaydta
ahr
h
tte
eeec
D
The generic OLTA user interface that has been personalized for a student is shown in
Figure 8-12. When a faculty member logs on the main screen will be the same with the
addition of a content "drag and drop icon" that allows faculty or TAs to input their
content.
After the content is dropped on the "up-load icon" a screen is displayed
requiring the input of a content type that was defined in Table 8-2. Next an attributes
screen customized for that content type is displayed that gathers the title, reference lID,
etc. for the content, please see Appendix B for more information. When content is input
into the OLTA the type and attributes are automatically stored in a SQL database and the
actual files uploaded are placed in a directory under the OLTA web root directory, this
can be seen in Figure 8-13.
82
Log on
Request
objAUO = Get( "cn")
Rule file determines
content
Web User
OLTA Site
Return query
results
.
Server
OLTA Root
PDP Phase
PDP Tasks
Homework
etc
Figure 8-13 Prototype Physical Implementation
This demonstrated the completion of the first three tasks along with a fully dynamic
front-end that also included some personalization aspects of the web. Tasks four and five
were simulated to give a general idea of the user interfaces.
83
Testing and Evaluation
Developing the OLTA prototype began with a typical software development spiral
process illustrated in Figure 8-13. Discussions with Dr. Blair, one of the participants in
the first testing phase, were very positive on the initial prototype vision and functionality
in phase two of the development process. Phases 3-6 were completed prior to the final
design review for the functionality highlighted in Figure 8-12.
One of the largest
problems encountered during the prototype development was the inability of the author,
Mr. Donovan, or Mr. Mitchell to maintain a stable development environment initially
caused by the author changing the web security permissions. The ultimate solution to
this problem was Mr. Mitchell lending the team a 300 MHz laptop with a good Site
Server build on it. This meant that the prototype laptop would be running, Windows
Advanced Server, and Internet Information, Indexing, Content Management, System,
LDAP, and the Site Server Indexing services along with SQL 7, which had the effect of
severely reducing the performance of the prototype.
*
8. Continue
*
7. Review and get feedback
1. Lay out Demo Templates
*
2. Get feedb ck from users
3. Hardwire D mo Templates
6. Persona ze OLTA pagt
*
*
4. Spe Database Objects
5. Tie TA content to atabase
*
Figure 8-13 OLTA Development Process
84
Testing the basic input, archiving, query, and retrieval of content functionalities was
performed and found to be satisfactory. Due to the abundant amount of software running
on the laptop, indexing and updating of the content was severely degraded. One bug was
discovered when a custom defined attribute was used. A visual basic script run-time
error occurred when an attribute was named "in" or "out," but this was debugged and
fixed relatively easily.
Recommendations for the OLTA production architecture and
lessons learned are presented below.
85
9. Assessment and Recommendations for Future Work
The DE-ICE project consisted of gathering and iterating the needs of the Aeronautics and
Astronautics Department for the development of a design environment for integrated
concurrent engineering.
Existing systems were researched and benchmarked to set
achievable goals for the system.
The team's research shows that in an academic
environment determining factors are:
1. Achieving good communication
2. Communication and documentation should be integrally linked
3. Integrated concurrent engineering sessions are heavily dependent on a leader to
maintain team focus and the tempo of meetings
4. User base may lack the experience to define their development process
5. Inexperienced engineers may have difficulty developing good first order models
Technical requirements were generated and iterated using a QFD requirements matrix to
find the highest driving requirements to satisfy the Departments needs. The team showed
that the highest technical requirements were:
1. Design and analysis support
2. Provide guidance throughout the design process
3. Planning and management of the design process
4. Experimentation support
5. Operate on any platform
6. Distance collaboration support
7. Flexible system
8. Presentation and reporting support
A QFD Product Matrix mapped the technical requirements to specific implementations
that allowed the team to synthesize architectures.
Pugh analysis showed that the
86
recommended architecture should have a similar implementation cost relative to the
baseline while:
1. Reducing the operational cost of the Department
2. Increasing the design functionality of the DC
3. Increasing communication functionality
4. Increasing the system flexibility
5. Supporting the operational modes defined for the system
Several concepts were generated for prototyping and one, the OLTA, was selected based
on satisfiy the technical requirements.
The OLTA concept proposed was centered on
providing a "roadmap" for students through the design process. This would be archived
by supplying relevant product development methodologies and quality work from past
projects that would help students understand how to plan and generate good designs. A
web-based interface to the OLTA would allow the students to access the information
where and when they need it.
A project navigator and work manager were also
incorporated in the OLTA to enable capturing of the evolution of the design and version
management
respectively. Please see Manka and Nolet for more information.
Additionally, Faculty or students could tailor the system to their projects. This concept
would add value to engineering education by giving the students the guidance and
knowledge they need to perform outstanding design work.
A proof-of-concept prototype was developed and tested.
Prototyping showed that
OLTA's functionality may be accomplished using a single user front-end. Capitalizing
on the personalization and membership functions from Site Server greatly expedited the
development process. Site Server contains most of the tools needed to develop the full
OLTA web site. It was difficult to discern exactly which tool was performing a specific
function, however, since Site Server is a collection of highly interconnected disparate
tools. This caused approximately two weeks of lost time in attempting to reconfigure the
system. Therefore, it is recommended that if the OLTA is developed using Site Server,
the site administrator would need training to fully understand the intricacies of Site
87
Server. Rule files to query the SQL database proved to be very useful and could be used
to build the graphic PDP. Development/production architectures for the servers need to
be seriously considered.
A recommended architecture is presented in the following
section. Content attributes also need to be defined globally and should be minimized
when the production system is developed.
In future development of the OLTA studies should be conducted to determine the level of
automation needed for the PDPs and the actual functionality desired by the student and
faculty users. During prototype development assumptions were made by the design team
as to how people will work and interact with the system. These assumptions would need
to be validated through usability testing and iteration of the user interfaces. Additionally,
the author believes that the version management concepts proposed by Simon Nolet
developed for the work manager would add value to the system if it could be developed
to function in the background, so as to not impose additional constraints on the students.
DOME needs to be fully tested to be sure that it will justify building new interfaces to the
DE-ICE specific tools, and will not add additional work to the users.
Production Server Architecture for OL TA
The architecture of the production servers for the OLTA is recommended to allow for
future scalability and load analysis to be performed on the hardware. By separating the
three servers an IT system administrator can more efficiently evaluate bottlenecks or
hardware deficiencies in the system [28].
A firewall needs to be designed to prevent
unauthorized users from gaining access to sensitive information (i.e. student grades) or
corrupting the system data.
During prototype development it became clear that the recommended architecture would
be necessary. If all the services are self-contained on a single machine the performance
(i.e. rate at which the content can be indexed) is severely degraded. When large amounts
of traffic are encountered the situation could become a serious problem.
88
Web Browser
Web Browser
Web Browser
WIN 2000 Advanced
Server
SQL database
LDAP Server
Knowledge Archive
Lightweight Directory
Access Protocal
Personalization and
Membership
Figure 8-12 OLTA Production Server Architecture
89
10. Conclusions
The goal of the DE-ICE project was to develop a recommended architecture of a design
environment for integrated concurrent engineering in an academic intuition, and to
identify/prototype a key enabler for the system.
The design of DE-ICE for the
Aeronautics and Astronautics Department differs from ones in industry due to the
pedagogical and operation needs which drove it. The Department's initiative sought to
create a stimulating hands-on environment that would reinforce the core engineering
fundamentals while exposing students to the difficulties of developing complex products.
During the course of the project three unique architectures were developed that should
satisfy the pedagogical and operational needs of the MIT Aeronautics and Astronautics
community.
Architectures varied in their physical, IT/software, communication, and
equipment components. The author's architecture was developed with the consideration
that increasing the frequency of communication, minimizing constraints of the physical
boundaries and the effects of varying student clock speeds would improve the quality and
productivity of the learning experience.
Analysis showed that the final architecture
ABC', which evolved from the original three, was the best architecture based on a Pugh
analysis.
During the course of the system architecting phase several prototype concepts "bubbledup," and the OLTA proved successful in addressing the highest needs of the Department.
The first phase of the OLTA development was implemented for testing and feedback
purposes to discover additional latent needs of the students and faculty. In the future, a
prototype should be further developed using the feedback gathered to date from the
faculty to gather additional feedback from the students who will be using the system.
Development of the OLTA should be of great value to design classes and CDIO projects
in the future, because it promotes active learning through self-direction, contentexperiential and case-based learning as compared to the more traditional "chalk talk"
form of engineering education.
90
The support and guidance offered by the OLTA is currently unavailable within the
Department or the Institute but would add value to engineering education because it
would help to produce engineering graduates who would be more well-rounded and
experienced in their understanding of the product development process and how to
navigate through a complex design process.
When the OLTA is fully developed and functional it would put an end to the current
method of having students and faculty with little or no design-development experience
expend their effort in the early stages of a class trying to piece together what needs to be
done to make progress on a project or design class. This valuable upfront time is wasted
in this mode of operation when it is needed most at the time when deliverables are due.
From an educational perspective this new DE-ICE/OLTA enabler should help the
Department produce engineers who not only have an understanding of the core
fundamentals, but understand how to start and conduct a development project. This will
make Dr. Sercel's comment "OLTA could revolutionize engineering education as we
know it" come to fruition.
91
11. Acronyms
AA
Aeronautics and Astronautics
ADR
Architectural Design Review
API
Application Programming Interface
AUO
Active User Objects
BOM
Bill of Materials
CATIA
Computer-Aided Three-Dimensional Interactive
Application
CDIO
Conceive-Design-Implement-Operate
COM
Component Object Model
CORBA
Compliant Object Request Broker
DE-ICE
Design Environment for Integrated Concurrent Engineering
DC
Design Center
DOE
Design of Experiments
DOME
Distributed Object-based Modeling and Evaluation
DIP
Swedish for meeting minute's application
DMU
Digital Mock-Up
DSM
Design Structure Matrix
EBD
Equipment Block Diagram
FMECA
Failure Modes, Effects, and Criticality Analysis
FX
Effects
UG
Undergraduate
G
Graduate
GA
Genetic Algorithms
GUI
Graphical User Interface
HW
Hardware
IMAGE
Intelligent Multidisciplinary Aircraft Generation Environment
IPD
Integrated Product Development
JPL
Jet Propulsion Laboratory
LAN
Local Area Network
92
MS
Microsoft
NASTRAN
NASA Structural Analysis Program
OLTA
On-Line TA
PAD
Product Attribute Database
PC
Personal Computer
PERT
Program Evaluation and Review Technique
PDC
Product design Center
PDP
Product Development Process
QFD
Quality Function Deployment
RTVP
Round Table Virtual Presence
SEMP
Systems Engineering Management Plan
SQL
Structured Query Language
STEP
Standard for the Exchange of Product model data
SW
Software
TA
Teaching Assistant
TR
Technical Requirements
NASA
National Aeronautics and Space Administration
VNC
Virtual Network Computing
VSA
Variational Simulation Analysis
WWW
World Wide Web
93
12. References
1.
Goldin, Daniel S. "Tools of the Future," Journal of Engineering Education
(1999): p. 31-35.
2.
MIT Department of Aeronautics and Astronautics. "Active Learning Enabled by
Information Technology," MIT I-Campus Proposal 1999.
3.
Slocum, Alexander H. Precision Machine Design, Society of Manufacturing
Engineers, 1992.
4.
Holmberg, Gunnar "Integrated Product Development-a Key to Affordability,"
draft ICAS paper Aug. 28, 2000.
5.
Pugh, Stuart.
Total
Design Integrated Methods
for
Successful Product
Engineering, Wokingham Eng: Addison-Wesley Publishers Ltd. 1991.
6.
Conversation with Kim Blair PhD, Center for Sports Initiative 4/6/2000.
7.
Sternberg, Robert J. The Nature of Creativity: Contemporary Psychological
Perspectives, New York: Cambridge University Press, 1988.
8.
Ulrich, Karl T., and Steven D. Eppinger. Product Design and Development, New
York: McGraw-Hill, 1995.
9.
Pahng, Francis, Nicola Senin, David Wallace. "Modeling and Evaluation of
Product Design Problems in a Distributed Design Environment," Proceedings of
ASME DETC'97, September 1997 Sacramento, CA.
10.
Linder, Benjamin. "DOME Presentation," MIT CADLAB. February 8, 2000.
11.
Pahng, Francis, Seokhoon Bae, David Wallace. "A Web Based Collaborative
Design Modeling Environment," Online. MIT CADLABFebruary 20, 2000.
12.
Hale, Mark A., Dimitri N. Mavris. "Enabling Advanced Design Methods in an
Internet-Capable Framework," Online. SAE Paper 1999-01-5578 February 21,
2000.
13.
Hale, Mark A., Dimitri N. Mavris, Dennis L. Carter. "The Implementation of a
Conceptual Aerospace Systems Design and Analysis Toolkit," Online. SAE Paper
1999-01-5639 February 21, 2000.
94
14.
Mavris, Dimitri N., Daniel A. DeLauentis, Mark A. Hale, Jimmy C.M. Tai,
"Elements of an Emerging Virtual Stochastic Life Cycle Design Environment,"
1999 World Aviation Conference, October 19-21, 1999 San Francisco, CA.
15.
"MIT Department of Aeronautics and Astronautics Strategic Plan," Cambridge,
MA: MIT Department of Aeronautics and Astronautics, 1998.
16.
Fredriksson, Billy. "Holistic Systems Engineering in Product Development,"
Product Development 16.882 Systems Architecture, MIT, Fall 1999.
17.
Fredriksson, Billy. "Holistic Approaches to Product Development The Gripen
Case" 16.882 Systems Architecture, MIT, Fall 1999.
18.
Sercel,
Joel and Stephen Wall. "Integrated Concurrent Engineering Design
Centers," California Institute of Technology 1998.
19.
"OMG Unified Modeling Language Specification," Version 1.3 June 1999.
20.
McMasters, John H., James D. Lang, "Enhancing Engineering and Manufacturing
Education: Industry Needs, Industry Roles," Boeing Aircraft Corp, Seattle WA
November 1,1995.
21.
"MIT On-Line Course Catalog." Online. MIT May 1, 2000.
22.
Class assignment. "Principals Document,"
16.882 System Architecture Class,
MIT, December 10, 1999.
23.
Crawley, Ed "System Architecture,"
16.882 System Architecture Class, MIT,
September 10, 1999.
24.
Holmberg, Gunar Interview, Bruce J. Farnworth. Linkoping, Sweden February
28, 2000.
25.
IBM Corporation. "IBM ThinkPad University," Online.
http://houns54.clearlake.ibm.com/solutions/education/edupub.nsf/detailcontacts/T
hinkPadUniversity, April 14, 2000.
26.
Boppe Charles W. "16.870 Aerospace Product Design Volume 1," MIT,
September 1999.
27.
Sercel, Joel C. "Introduction to Integrated Concurrent Engineering (ICE),
ICEMaker, and Drawcraft," 16.89 Space Systems Engineering, MIT, April 2,
2000.
95
28.
Apostolopoulos, Hick et al. Professional Site Server 3.0. Birmingham: Wrox
Press, 1999.
29.
Lean Enterprise Model. Cambridge, MA, MIT Lean Aerospace Initiative, 2000.
30.
Manka, Alex. "Developing a Design Environment for Integrated Concurrent
Engineering (DE-ICE) in University Education: Integrating Student Designers,
Design Tools, and Active Learning," MIT Thesis, May 2000.
31.
Nolet,
Simon.
"Implementation
of a Design
Center
in
an
Academic
Envireonment: DE-ICE Project," MIT Thesis, May 2000.
32.
Wikstr6m, Roland "DMU Room Presentation," Linkoping, Sweden, February 28,
2000.
33.
Williamson, Christopher, et al. "Perspectives on an Internet-Based Synchronous
Distance Learning Experiences," JournalofEngineeringEducation Jan 2000.
96
User Needs
13. Appendix A
Definition of the DE-ICE Needs:
Introduction:
Today MIT is embracing the CDIO methodology in order to produce graduates
that understand the complex and iterative nature of designing a product.
Traditionally students have been taught with a discipline-specific methodology,
never really understanding the effects of design decisions as a whole.
DE-ICE is a design center that will enable students to understand the global view
involved in design decisions. It will support the design and development of
hardware, software, and liveware. DE-ICE will integrate design process models
and enable students work concurrently.
Pedagogical needs:
1. Capability to support MIT operational modes:
(WEIGHTING FACTOR constraint)
MIT has defined approximately 20 operational modes that range from teaching in
labs to paper design mode. The DE-ICE system should be designed to support a
number of these modes, principally:
Design project mode
Short Time Frame
Priority
e
Long Time Frame
1
16.82/.83
16.684
2
16.89/.891
MEng
3
16.00
Lecture/presentation mode.
97
Also relevant to these modes are:
e
Large systems mode
e
Collaborative project mode
e
Research design support mode
*
Distance learning/teaching mode
e
Interactive electronic class mode
Key elements inherent to each mode are: team-based design, lab experiments,
engineering trade studies, design-build-operate-report
projects, distance
collaborative design teams and teaching/ interactive classes. Teams working on
these projects may be geographically dispersed and working at varying clock
speeds or time zones. Team size will also vary from 2 or 3 which require fairly
straightforward communication to large teams with approximately 10 to 20 multidisciplinary teams which require extensive project planning and management
solutions along with more complex communication and meeting services.
Distance Learning has the capability to expose local and remote students to
experts in industry and academia that will give them different points of view and
knowledge.
2. Active Learning in a Design Environment
(WEIGHTING FACTOR 10)
Because the design of a complex system cannot be easily taught solely by passive
learning, a method of discovering how complex systems are designed is through
the process of designing a system. Learning modes that can be used are:
e
Content experiential
i.e.: Hands on experimental
e
Project-Based Learning
e
Case-Based Learning
98
"
Engage With Principals
i.e.:
Chalk talk with class discussion
Think-pair-share
e
Self Directed (Ref Grow)
(WEIGHTING FACTOR 9)
3. Holistic View of Design
Design entails understanding the needs of the customer, conception, analysis,
iteration, planning, coordination, synthesis, and communication.
System designers
need the ability to break down a complex task in to manageable chunks so that each
one can be developed without the designer being overwhelmed.
Integration of a
design is the aggregation of individual models/chunks into a whole that can be
efficiently analyzed against a given set of requirements and simply modified to fully
explore the design space. A good design is one that delights the customer meeting or
exceeding their requirements, is safe, and is environmentally designed. Designing a
system while taking into account the lifetime of the product and understanding the
life cycle costs of a system are key to the design of modern systems.
DE-ICE should enable students to perform system wide design analysis and trade
studies.
Design for "X" should be integrated into the product model to enhance
understanding of the influences wrought by manufacturing, assembly and operation
has on the design decisions.
A key to the success of this system is to manage the
perceived complexity of the system being designed.
4. Improved knowledge of and experience with the design process
(WEIGHTING FACTOR 8)
By utilizing the DE-ICE system the hope is that students will gain knowledge and be
enabled to make mature decisions early in a design process. Because students are
making these decisions and may lack "experts knowledge," care must be taken to
avoid the possibility of premature closure of a decision.
TRIZ (ref ...) techniques
99
may help students to overcome their relative lack of experience.
Simulation and
modeling will be provided to allow students to establish estimates of the behavior of a
system (i.e. dynamics, thermal, structural, etc.), costs estimates, performance
estimates, manufactureability, assembly, and operations.
5. Support of life cycle analysis
(WEIGHTING FACTOR 5)
DE-ICE should provide or support the integration of new tools that can be used
for any phase of the design.
The system should support needs, requirements,
functional, and behavioral analyses, interface specification, functional to physical
mapping, testing and verification planning, detail design, digital mock ups,
manufacturing and assembly, Variational Simulation Analysis (VSA) (ref. ..),
operational planning, operational
support, testing and data collection, and
disposal.
Operational Needs:
6. Improve the quality of student design work
(WEIGHTING FACTOR 7)
DE-ICE should enable users to observe the system design from varying perspectives.
The system should improve the quality( i.e.: depth of analysis, manufactureability) of
designs by allowing users to consider the downstream influences on the design
(fulfilling the requirements, depth of analysis, reducing reworks, ease of manufacture,
delighting the customer, etc.). The system should provide a method to analyze the
product and the design/manufacturing process and evaluate their fit. By integrating
models and simulations, DE-ICE should enable students to iterate a design to achieve
a much higher quality design than could be done previously when team member were
working on separate models.
Providing a knowledge database that students can
utilize and contribute to can improve their design and will provide benefits for future
100
projects. Easy access to expert help may also help students improve the quality of
their designs.
Ultimately the goal of DE-ICE is to improve student designs and
understanding of the design process, also there should be some means of testing this
improvement.
7. Increased productivity for a given amount of time
(WEIGHTING FACTOR 7)
The system should increase the productivity of the teams so that more time can be
spent on the design and not wasted learning new software or performing repetitive
tasks. All of the design models from each phase of the design should be able to
be linked so that a complete life cycle analysis can be easily performed. Users
should be able to make changes to any part of the design and see the effects
automatically. Design data should be easily accessible to the team while allowing
limitations to be set so that the team has control of the design parameters. Design
parameters should be maintained by DE-ICE so that users can select critical
parameters for informational display.
Drawings, charts, graphs, and diagrams
should be easily extracted for use in reports, presentations, or electronic
discussions.
8.
Highly useable system
(WEIGHTING FACTOR 4)
The system should be intuitive so as not to add complexity to the design process.
Users should be able to use familiar tools and software interfaces when working
on the system. Integrating data into a model or running a global optimization on
the system should be simple tasks and not be time or effort intensive. Multiple
design variants should be easy to create, change, compare, and merging design
elements into the system should be simple but with the team having some controls
over what design parameters or modules get modified and when.
The learning
curve of the DE-ICE system should be low so that users get into the "added value
range" quickly, possibly less than a few days. Students should be able to work on
101
the design from any location and not be constrained to the lab. People should
want to use the system, it should be an enjoyable experience (Hennessey &
Anabile, 1989) so that students will be drawn into its use. Possible metrics: new
users' capabilities vs. time, hours logged in on-site vs. hours logged in remotely.
9. Support for team enablers
(WEIGHTING FACTOR 7)
For the design teams to work effectively they must have simplified usable
communications, easy access to design information and access to knowledge
about the design.
Since the teams may be non-colocated gathering the design
team members for meetings or reviews may be impractical. Therefore the system
should support electronic meeting services where information can easily be
shared.
The system should also have the capability for audio and video
communication so non-colocated team members, guest lectures or expert help can
communicate.
10. Flexible system (Sustainability)
(WEIGHTING FACTOR 6)
Features of the system should be easily configurable to work in a stand-alone
component design or configurable to any user's needs. Users should be able to
operate the system on any computer platform. This is important considering the
different OS platforms currently utilized by faculty and students. Integration of
data or the ability to use new analysis tools in the DE-ICE system should be a
simple task.
102
DE-ICE Needs
Hierarchy
Capability to support
MIT operational
modes
Active Learning in
a Design
Environment
Improved
'knowledge of and
experience with
.the design process
Holistic View of
Design
Improved the
quality of student
design work
Increased
productivity for a
given amount of
time
Highly useable
system
Support of life
cycle analysis
Support for team
enablers
Sustainable
system
DE-ICE User Needs Hierarchy
103
14.Appendix B
Baseline Architecture
Other Design
Rooms
DE-ICE
Baseline
IT/Software
View
Course Management
and Delivery
MIT A/A I
LAthena
Faculty
TA's
Design Roi
[Je sign
Room Server Windows 2000
Staff
KEY:
Personal
Folders for
Students
Windows NT Workstation
Software
Installation
Server
Users
Office
-
_
NetMeetin
IBM Compatible
100 Mbps Ethernet
Cost
Database
www
Shared
Folders
for Users
ProE
Database
External
Users:
Students
Faculty
Lecturers
Customers
Vendors
Sub-Systel
Models
M
Matlab
MathCAD
MS Office
NetMeeting
Group E-mail
Pro E
STK
ORCAD
NASTRAN
Compilers
LabView
MasterCam
CFD
Adobe Acrobat
Baseline Software/IT View
104
AA Server AA Server
Links to
labs,
faculty
and TAs
-
-
Baseline Physical View
105
15.Appendix C
Survey
At#CltiNp //gotharncity/projed -surveyebpg
ms
The MIT Department of Aeronautics and Astronautics is currently investigating of the next generation of Design Environments for
Integrated Concurrent Engineering for learning (DE-ICE) in collaboration with Microsoft Inc DE-ICE will enable integrated
engineering and collaborative communication among a distributed multidiscipline engineering team. The system will be used by MIT
undergraduate and graduate students in design classes and extended projects.
This survey will be kept completely anonymous
This effort will be greatly enhanced if you would take a few minutes to give us your feedback
- ----
----------------------------------------------------------...............................................................
.......................
1 Please tell us about yourself:
0
Under Graduate Student
Years of university experience
:Years
of industry experience
3-
r
.
.C..
6-10
r
10+
.
Age
If you would like to include the organization that you are
associated with please feel free to do so
Have you used an integrated engineering environment, if so
how much
What proportion of your time is spent in teams n
engineering proj ectsN
Have you had any formal training in tearn dynarniCs/
NA
NA
working in teams
jNA
Have you had any training in team problem solving skills
2
What is your preferred Operating System:.
3
Importance of design tools:
INA
Please rate the importance of these tools for your work
Hi
= Can't Live Without
106
:p.s.jJnr/giamciayprojsn
survsy_ weo-page asp
............
Med = Often Useful
Low = Rarely Useful
(please select all tools you regularly use)
ProE
NA
Matlab
NA
4
CATIA
AutoCAD
INA
Mathematics
MathCAD
NA
DCRS
NA
3
RDD100
Fortran
INA
3
C+/C++
|NVA
NA 7
.Java
NA
3
Basic
NA
Nastran
INA
3
IDS
NA
'vensim
]
ADA
NA
.DEAS
I
3
|NA 3
NA
INA . ,
Net Meeting[N
3
MasterCam
3
NA
Visi
ACSL
MatrxX
Visual Basic NA
Turbo PascaliNA3
Interactive Data
:Language
3
DrawCraft NA
INA
.ANSYS
3
3D Studio
NA
NA
3
*"-"''*-'-*"-----'-*..-.-.--...---------------------------.------...--.----.--------.
.----------------------------------------------.-----------.....---.----------.--.
............. -...--.................------.--------............----...
...
............
MS Excel
NA
MS Office
NA
4
Lotus 123
J
NA
MS Project NA
MS Access
Corel Office
primavera
INA
NA
N
Other
........
Please rate the importance for effectiveness and efficiency of the design process:
Important Very
Some
Not
Software and System Usability
C
C
C
C
System Speed
Learning Curve for New Tools
C
C
Ability to Work Anywhere
C
Graphical Capability and Visualization of Data
C
C
C
C
C
C
Ability to use Familiar Tools
c
r
C
C
C
C
C
rC
Communication with Team Members
The ability to share data easily
C
C
C
Integrated Tools
Critical
Important Importance
Important Importance
C
107
psw~we~wriiip~giii~iecijpruje
.
."~
......
....
Preferred Cornmunication methods
Email
C
C
Phone
C
C
Tele-conferencing
C
C
C.C
Audio/Visual Presentations / Corrnmnmication
Face/Face
r
C
C
7
C
73.
Other
5
C
C
Fax
C
How do you best communicate ideas and concepts to your team members
Sk:etces
NA
Discussion
Memos
NA
Prototypes NBriefings
Models
DesignReviewiNA
Meetings
NA
NA
Graphs
Phone/Fax
NA
Other
NA
Email
nformal
6
NFace
Presentations
NA
to FaceNA
j
ByAccidet
NA
Shared DatabaseNAA
NA
How do you communcate factual informnation with coworkers/team members:
Sketches
|NA
Emai
NAReports
7
Reports
Memos
A
NA
j
Models
A
Shared DatabasefAf
Dscussion
NA
Presentations
NAnformalFa
NA
NA
;Graphs
Other
NA
_________
What do you find ae theliiting factors of the following
Response
Time
Sketches
C
Lack of
Feedback
C
Represent
Complex
Ides
Varying
Interpretations
Ote
C
108
diddf&E
]
http//gosthemcity/project.sueyweb-page.asp
___ji
it
Models
r
e
'Graphs
e
e
'Phone
i-
it
r
Eail
e
C
e
r
i
'
rC
C'
a
rt
C
Meetings
Other
8
rt
i
What is important in limiting your ability to share engineering data/information:
Some Importance
Not important
Different file formats
i'
Slow I no network
C
i
i
e
ery large files
Undefined system interfaces
.
on-static interfaces
e
i
.
i
nTnterdependent data
INot located with team members
Critical
V.ery
Crta
Tprt
portance!
ninportanit
Important
i
Different operating systems
i
i
i
Some importance
Important
Other
9
j
re
Discussion
'Reports
Presentations
_
.
i
What would make you more inclined to using an mtegrated enineering environment:
Not Important
.IfIknow the tools
Ease of use
Onse helpi
i~
Very
Critical
Cptan
Vepr
lntportanoe
Imnportanit
i~
(7
-r
109
rmp:jjqaihamcttyj p rajeq-survey.
a-p ag e.asp
....
...
... ..... ......
... .........
................
.........
..........
What would make you more inclined to using an inteirated engineering environment:
9
Not Important
.IaflI
. ..............
......
----..........
......
. .......
.......
....
Inow the tools
Some Importance
Important
iCritical
Very
VerytCrtal
lmorIIlportance:
C
C
*ase of use
c
*Online help
Demonstrations or classes
Abilitytc integrate and access data from other applications
Mandate from upper management
nd to end product development tools
Reduce repetitive tasks
Reduce the time needed to develop a design
design quahty
nimprove
Understand what the limits of the underlying models are
c
C
C
C
C
C
'
C
C
C
C
C
r
C
l
eC
Have a thorough understanding of the underlying models used in the
environment
Other
C
Other
10
C
C
Please add any additional comments that you think would help make an integrated engineering environment better:
. ......
............
.....
..
...
110
Existing System Architectures
16.Appendix D
7~~NSORE~7
PROJ ECTON S C EE
7~NSORE~7
\PROJECTON SCEEN
Cost
f
4
Telecom-
TelecomHardware
NASA JPL PDC
Subs
Subs
+
*
Subs
Subs
-
-
III
ILunch & Coffee Table
X .,
X~b!E4
TRW ICDF Lab
112
PDMO
Matrix
EQ
Specs
ICD's
Componen
t Database
ACS
DMS
TT&C
EPS
ESDI
SMS
Thermal
Subcontract
s Database
Vendors
Contract
S
P O's
ICDF Tool Set
113
17.Appendix E
Architectural Variants B and C
MIT A/A Department
-Faculty
-TA's
-Students
-Staff
Design Roo
Pn
Printer
External
Lecturers
Photocopier
/ Fax
Cameras &
SEMP
System
Summary
Spreadshe
External
Viewers
-Customers
-Vendors
at (Fxceli
TRIZ
Tool
Hel
DS
Home & External
QF
Lull
Workstations for
Collocated
Telephone
L - - .......
_. -_.-..
...........
_.
.)
Workstations &
Home
Computers
-Develop
subsystem
models
-Disciplinespecific tools
-System
Architecture C Software/IT View
114
Software (on servers)
Windows 2000
MS-Office Premium
Emulators (UNIX, Mac, PC)
Matlab
Maple
Excel
MicroGraphX
DSM tool
1-DEAS
STK
Microsoft Project
VisioTechnical
VNC
Catalogues
NetMeeting
CVV
Ice-Maker
MasterCam
External Labs / Facilities
Video projector
Video Bus
Mous
MueiKeyboard
o
T
H/W switch
3i
Athena
PC Camera
Plotter
t
IP camera system
(ViewStation)
Net Phone L
4
Docking station
Digital copier/printer/scanner/fax
Mac Server
A
./e
Tethe
Laptop computer
Faculty members / TAs
A
UNIX Server
*
*
ImIinI~
I
I
h
PC Server
I
Ethernet
Internet
Architecture B Equipment Block Diagram
115
DE-ICE Architecture B
Physical View
Legend
~JE
2
= Docking Station
= Laptop Computer
= White Board
Architecture B Physical View
116
18.Appendix G
3
3
3
3
Project Schedule
PHroject titan
Research Learning I Work Mai
Techniolgy Review
Personal Interviews
Project Meeting
Define Project Needs
Create Survey
Develop System Requirement
Conduct Survey
Trip to NASA, CalTech, Aeros
Benchmark Current Systems
Preliminary Requirements Rev
Trip to SaabAB
Define Project Goals
Functional Analsis/Design
Concept Development
Trade and C/B Studies
Identify Subsystem for Protot
Critical Design Review
Prototype Subsystem
Project Design Revirew
PDR Project Schedule
lav
ID
TaskName
1
Project
Start
51
/ WorkModels
Learnmg
Research
6
Review
Technology
8
Personalntervews
22
for use inDE-ICE
teachingprocess
Define
4
Meetng
Project
2
DefineProjectNeeds
3
Create
Survey
12
Requirements
DevelopSystem
7
Conduct
Survey
10
9
4
7
10 | 13 1 16
19 22
25
n
2
3
21
1
21
24
27
1
May
|,April
Ma
FNeuav
31
4
10
13 16
19
22 |25
28
31
3
6
9
12
15
18 21 | 24 [27 | 30 1 3 [ 6 |
TRW.and
TriptoNASA.
Cal~ech.
Aerospace.
Benchmark
Cun-entSystems
14
Preliminary
RequirementsReview
11
Tnpto SaabAB
13
Defne ProjectGoals
15
UseCaseAnalysis
16
Concept
Development
18
Trade
andC/BStudies
17
forPrototyping
Subsystem
identify
19
DesignReview
Architectural
20
Subsystemf
Prototype
23
and desig
withCommunication
Epenimentation
25
andSearchCapal
DevelopKeyObjectCapture
24
DevelopOn-lneTAfront-end
26
TestObjectCaptureandSearch
27
TAfor Demo
On-Line
Populate
21
ProjectDesignRa
ADR Project Schedule
117
9 | 12 1 15
18 |21
ID
Task Nam.
1
ProjectStart
ary
4
7
10| 13
16
19
22 25
28
3
Fktruarv
1
912
21 24 | 27
15 1
Mar,
1
14
10
1
16
16 22 | 25
Aprl1
31 3
1 28
Mi
1Research
Learnmg/
WorkModels
TechnologyRevew
8
PersonalInterviews
22
Defineteachingprocessfor use inDE-ICE
4
ProjectMeeting
2
DenineProjectNeeds
3
CreateSurvey
12
DevelopSvstemRequirements
......
.....
. .....
...
.
i...i
7
1in
9
ConductSurvey
TniptoNASA.CalTechAerospace TRW.and
iBenchmarkCurrentSystems
14
PreiminaryRequirementsReview
11
TnptoSaab AB
13
DefineProiectGoals
15
Use CaseAnalysis
16
ConceptDevelopment
Tradeand C/BStudies
17
IdentifySubsystem(or Prototyping
DesignReve
Architectural
PrototypeSubsystem
El El -
Expenmentahon
wth Communication
and desig
25
DevelopKev ObjectCaptureand Search Capat
24
DevelopOn-ineTA front-end
26
Test ObjectCaptureand Search
i
PopulateOn-LtneTAfor Demo
211
ProjectDesignReview
DE-ICE Final Project Schedule
6 | 9 | 12
15
18
21
24
May
27 30 3
6
9
12 |15 1
21
19.Appendix H
Active Learning Course Descriptions
Ref [21J
16.00 Introduction to Aerospace and Design
.
(.)
Prereq.: -Units: 3-1-5
URL: http://web.mit.edu/16.00/
M Lecture: TR9:30-]I (1-390)
TFhe findaiiental concepts and approaches of aerospace engineering are highlighted through lectures on aeronautics, astronautics, and design. Student
teams are immersed in a hands-on, lighter-than-air (LTA) vehicle design project where they design, build, and fly radio-controlled LTA vehicles.
The connections between theory and practice are realized in the LTA vehicle project. Required design reviews precede the LTA race competition.
The performance, weight, and principal characteristics of the LTA vehicles are estimated and illustrated using physics, mathematics, and chemistry
known to freshmen, the emphasis being on the application of this knowledge to aerospace engineering and design rather than on exposure to new
science and mathematics.
D. J. Newman, R. F. Perdichzz
16.684 Experimental Capstone Subject
Units: 4-4-4
Lab: TRJ-4 (9-151)
This class is scheduled for Spring 1999-2000, but does not have a description in the Course Catalog.
16.82 Flight Vehicle Engineering
- - -()
Prereq.: Permission of department
Units: 3-3-6
M Lab: TR3-4:30 (37-212) Lecture: TR2 (37-212)
Design of an atmospheric flight vehicle to satisfy stated performance, stability, and control requirements. Emphasizes individual initiative,
application of fundamental principles, and the compromises inherent in die engineering design process. Enrollment restricted to seniors in Course
XVI who have satisfactorily completed all other Departmental requirements for the S.B. degree, or by permission of instructor.
M Drela, Staff
16.83 Space Systems Engineering
Prereq.: Permission of department
Units: 3-3-6
Design of a complete space system, including systems analysis, trajectory analysis, entry dynamics, propulsion and power systems, structural design,
avionics, thermal and environmental control, human factors, support systems, weight and cost estimates. Students participate in teams, each
responsible for an integrated vehicle design, providing experience in project organization and interaction between disciplines. Enrollment is
restricted to seniors in Course XVI who have satisfactorily completed all other Departmental requirements for the S.B. degree, or by permission of
instructor.
D. W Miller, Staff
16.89 Space Systems Engineering
.(.).
Prereq.: Permission of instructor
Units: 4-0-8
[ Lecture: MWI-3 (4-144)
Subject defines what a systems engineer does, and reviews the unifying concepts which are applicable across many disciplines. Examples drawn
from major national programs. Principles of good practice are developed and applied to current government and commercial space programs. Class
specifies and designs a space system.
D. E. Hastings,J M Warmkesse/
119
16.872 Aerospace Design Project
Prereq.: 16.870, 16.871, 16.ThG
Units: 1-0-2
IlLecture: W9
Provides the supervisory framework for the M.Eng. Design Project and Thesis. Multi-disciplinary student teams (3-6 students per team) are
structured to focus on design projects recommended by industry and faculty. Projects address aircraft, spacecraft, or aerospace product subsystem
design requirements. Student-prepared design review presentations are scheduled at several points during the Spring Semester. These presentations
are attended by department faculty and industry representatives. Restricted to Master of Engineering students who co-register for 16.ThG.
C. W Doppe
120
20.Appendix I RTVP Concept
.........
.....
.....
...................
.............
..............
............ . ......
.. ... .. .. ...........
... ........
RTVP Conceptual Illustration
121
21.Appendix J Electronic Whiteboard
text
text
text
text
DI
I
7
2J
/
17-
/
/
/
PCL
...........
.... iiiiiii.~
Laptop
External users
............
..
lutrt
Electronic
W..teb...
122
22.Appendix K Recommended Software
Software title
Adobe Acrobat Creator
Class
Additional
request
software
Recommendation
16.83
Adobe Acrobat Reader
X
Every computer needs Adobe to
read pdf files
Adobe Framemaker
16.83
Adobe Illustrator
16.83
AutoCAD
16.83
CFD package
X
A CFD package is a necessity for
aircraft design
Distance Learning
software
X
DOME
X
Design specific tool integration
Exceed (X-windows
emulator)
X
Ability to work in the Unix
LabView
Needed to support operational
mode
environment at a PC
16.684
X
Experimentation support
LaTeX
X
Report and presentation support
Mac Emulators
X
Ability to work in the Mac
environment at a PC
Macromedia Director
16.00
Maple
16.83
MasterCam
X
Manufacturing and tool path
generation
Mathcad
16.881,
Unified
Matlab
16.00, 16.83
Matlab C Compiler
16.83
Matlab Control System
16.83, 16.31
Toolbox
123
Matlab Partial Dif Equ
toolbox
Matlab Real Time
Toolbox
Matlab Signal
16.83
16.83
16.83
Processing Toolbox
Matlab Simulink
16.83
Matlab Symbolic Math
16.83
Toolbox
MS Front Page 2000
MS Office
X
Web creation and management
X
Excellent graphic and
16.83,
16.684
MS Project
16.83
MS Visio Technical
2000
diagramming tool
MS Visual Basic
X
Software design support
MS Visual C/C++
X
Software design support
MS Visual Studio
16.83
NASTRAN
16.684
NetMeeting
LAB
ORCAD (pcb and
16.83
electronic design)
Pro-Engineer
16.00, 16.83,
16.684
PSM-32
X
-
Windows based design structure
matrix tool, not as powerful as
DEMAID
QFD-Capture
X
Supports needs, requirements,
benchmarking, etc matrices and
reports...
Quick Time Pro
16.00
Satellite Toolkit
16.851
Shock Wave
16.00,
16.423
124
Software testing and V
X
Software design support
X
Visual modeling, UML, 00
development, testing, life cycle
& V tools
Software Through
Pictures
software design tool, automatic
code generation,
Stat-Ease
16.684
X
Excellent DOE tool, generation of
2-D and 3-D response surfaces
X
TechOptimizer
TRIZ tools, patent searching,
filtering, and optimization
Thomas Register Online
X
Ven Sim
X
Excellent source for brain storing
and component identification.
Very user friendly visual
simulation environment
Virtual Network
Computing (VNC)
Virtual Workbench
X
Remote access application
X
3-D manufacturing and assembly
simulation environment
Web (netscape or**
explorer
WinFax Pro
Working Model 3D
16.684
X
Fax software
X
Very good tool that integrates 3-D
CAD drawings, dynamic
simulation FEA, and CFD, import
and export in standard CAD
formats.
125
23.Appendix L Saab AB DMU Room Presentation
DMU-ROOMI
GOAL
-Reduce turn around time
- Spead up the decision process
- Increase concurrent engineering
WORK
MEETINGS
DECISIONS
REVIEWS
WORK
DECISIONS
I
MEETINGS...
REVIEWS
- Postpone drawings
- Reduce the number of docurnents needed to produce during development procesg
DMU-.ROOM
IMPLEMENTATION
-Software for online manipulation of:'f
-Cisah and clearence analyses
-Visualization
-Assembly simulation
-Solid modeling
"Acess to good graphic performance
- Large sized image projection
126
DMU-ROOM
IMPLEMENTATION (Cont'd)
-Way of working
- Frequent meetings
- High speed of decision making
- Review mainly in 3D environment
- The DMU is a corner-stone
- Minutes act as log of the WP (graphic & text)
-Minutes handling
- Standardised design of the minutes
- Some preparations of the minutes before the meeting
- Minutes written simultaneously at the meeting
- Certain coordinators write the minutes
- Cut and paste from the CAD models into the minutes
- Minutes finished by the end of the meeting
IMPLEMENTATION (Cont'd)
-Minutes handling (Cont')
- Minutes available on Intranet directly after the meeting
- Minutes are "officially decision documents" during the development r
EXPERIENCES
-Room /Equipment
- Enough room space
- Good graphic performance is needed
- Don't underestimate environment issues (light, acoustics. tem.
-Software
- Well tested
- Train a fewv entrepreneurs
127
DMtU-ROOMI
EXPERIENCES (Cont'd)
-Methods
- Develope methods within an ongoing project
- The method evolves by active participation from end users
- The over all release process acts as a framework
- Some difficulties to leave old methods
- Hesitation to update DMU in early phases
- Unfamiliarity with frequent meetings
- Coordinator/minutes writer must be trained
- Important to kdep satisfactory tempo at the meetings
- In spite of access to 3D models, stress people want
rough drawings in early phases
EXPERIENCES (Cont'd)
-Effects of DMU room /software /methods
- Collisions discovered much earlier
- Shorter decision ways ==> Quicker decisions
- Compact and ebasy-to-interprete minutes
- Certain postponing of drawings (great potential)
-Less time needed for review
128
KOSTNADER FOR DMU-RUMMET
Storbildsutrustning
625 Ksek
Graf ikutrustning
200 Ksek
PC
20 Ksek
lordningst~llande av rum
130 Ksek
Konsultinsats
585 Ksek
129