development of a concurrent design facility based on esa ... · the concurrent engineering approach...
TRANSCRIPT
Development of a concurrent design facility based on ESA CDF: Application to aircraft design
Vasco José da Silveira Pereir
Dissertação para obtenção do Grau de Mestre em
Engenharia Aeroespacial
Presidente: Prof. Fernando José Parracho Lau (DEM)
Orientador: Prof. Paulo Jorge Soares Gil (DEM)
Vogais: Doutora Ana Filipa Caetano Relvas (Critical Software)
Prof. Filipe Sz
Março de 2009
of a concurrent design facility based on ESA CDF: Application to aircraft design
Vasco José da Silveira Pereira
Dissertação para obtenção do Grau de Mestre em
Engenharia Aeroespacial
Júri
Fernando José Parracho Lau (DEM)
Prof. Paulo Jorge Soares Gil (DEM)
Ana Filipa Caetano Relvas (Critical Software)
Prof. Filipe Szolnoky Ramos Pinto Cunha (DEM)
of a concurrent design facility based on ESA CDF: Application to aircraft design
Dissertação para obtenção do Grau de Mestre em
Ana Filipa Caetano Relvas (Critical Software)
ii
Aos meus Pais e Irmã
iii
Abstract
The concurrent engineering approach to project design was developed as an answer to the
challenge of overcoming limitations of the traditional sequential approach, where lack of
communication between the design, production, and marketing departments lead to suboptimal
results. Involving all people in the design from the beginning lead to better and cheaper
products as all aspects determining the final resulting design can be taken into account since
the beginning. The boom in information technologies emphasizes still more the advantages of
this integrated approach, leading to huge productivity gains, better designs, and ultimately to
innovation.
In this thesis the “Student Concurrent Design Environment” (SCDE), provided by the European
Space Agency, was implemented at the Aerospace Laboratory of Instituto Superior Técnico. A
possible layout for the concurrent design facility, scaled down from the ESA Concurrent Design
Facility (CDF), to meet the requirements of available space and academic environment was
proposed. The implementation includes, after the complete and correct installation of the SCDE,
the understanding and description of the system working process, including a discussion of
some detected critical aspects.
Once the system was working a test model was developed to verify the complete functionality of
the system and as an application of a different domain, having in mind the academic
environment. The selected design goal was a radio controlled aircraft, prepared to participate in
the Aircargo Challenge student competition. The application proposes some small add-ons in
the system, especially adequate to a student environment such as some knowledge
management rudiments to pass lessons learned from student of one year to the next.
The entire SCDE system works through the Microsoft Excel usage. The new application was
developed using this program as well as the Microsoft Visual Basic Editor, to create and edit the
functions applied to macros.
Keywords: Concurrent Engineering; Concurrent Design Facility at University; Aircraft
Concurrent Design; Aircargo Challenge Competition.
iv
Resumo
O método apoiado em Engenharia Concorrente para o desenvolvimento de projectos, apareceu
como uma resposta às constantes limitações existentes no tradicional método sequencial, onde
a falta de comunicação entre os departamentos de concepção, produção e comercialização
conduziam a resultados abaixo do esperado. O envolvimento de todos na concepção a partir
do início resulta em produtos melhores e mais baratos, dado que todos os aspectos que
determinantes para o resultado final, foram tidos em conta desde o inicio. A evolução nas
tecnologias de informação acentuam as vantagens do método integrado, levando a enormes
ganhos de produtividade, melhores projectos e por fim a inovação.
Nesta tese foi implementada a ferramenta “Student Concurrent Design Environment” (SCDE),
disponibilizada pela Agência Espacial Europeia, no laboratório de aeroespacial no Instituto
Superior Técnico. Foi proposta uma solução para a criação de um centro de projectos, a partir
do ESA-CDF, tendo em conta o espaço existente e os objectivos académicos. A
implementação compreende, após a instalação do SCDE, o entendimento do funcionamento do
sistema, bem como do seu desenvolvimento nas áreas de maior necessidade.
Estando o sistema em completo funcionamento foi desenvolvido um modelo de test para
verificar todo o funcionamento do sistema bem como sendo uma aplicação de um dominio
diferente, mas dentro da área académica em que se insere o trabalho. O modelo escolhido foi a
criação de uma aeronave controlada por rádio, preparada para participar no concurso “Aircargo
Challenge”. Esta aplicação sugere pequenas evoluções no sistema, especialmente adequadas
para um ambiente académico, tais como a criação de uma base de conhecimento para
transmitir as lições apreendidas para o futuro.
Todo o sistema SCDE funciona através do Microsoft Excel e todos os desenvolvimentos foram
feitos, através do uso deste programa, bem como do Microsoft Visual Basic Editor, para a
criação e edição das funções usadas a partir de Macros.
Palavras-chave: Engenharia Concorrente; Engenharia Concorrente em Ambiente Universitário;
Projecto de Aeronave utilizando Engenharia Concorrente; Competição “Aircargo Challenge”.
v
Table of Contents
Abstract ............................................................................................................................. iii
Resumo .............................................................................................................................. iv
Table of Contents ................................................................................................................ v
Index of Figures ................................................................................................................. vii
Index of Tables .................................................................................................................... x
Abbreviations ..................................................................................................................... xi
Index of Symbols .............................................................................................................. xiii
1. Introduction ................................................................................................................. 1
1.1. Traditional Approach versus Concurrent Engineering .................................................. 1
1.2. The Aircargo Challenge Event ....................................................................................... 4
1.3. Objectives and Motivation ............................................................................................ 4
1.4. Thesis Outline ................................................................................................................ 5
2. CDF in the World .......................................................................................................... 6
2.1. Introduction .................................................................................................................. 6
2.2. ESA-CDF ......................................................................................................................... 6
2.2.1. Overview ............................................................................................................... 6
2.2.2. Main objectives ..................................................................................................... 7
2.2.3. CDF Organization ................................................................................................... 7
2.2.4. Developments in Progress ................................................................................... 14
2.2.5. Why choose ESA-CDF .......................................................................................... 16
2.3. NASA – IMDC ............................................................................................................... 17
2.3.1. Introduction......................................................................................................... 17
2.3.2. IMDC People ........................................................................................................ 17
2.3.3. IMDC Process ....................................................................................................... 18
2.3.4. IMDC Tools .......................................................................................................... 19
2.3.5. IMDC Facility ........................................................................................................ 20
2.4. Other CE facilities ........................................................................................................ 21
2.4.1. German Aerospace Center .................................................................................. 21
2.4.2. European Aeronautic Defense and Space Company (EADS) ............................... 22
2.4.3. The Aerospace Corporation ................................................................................ 22
3. The SCDE System ........................................................................................................ 24
3.1. The Model ................................................................................................................... 24
vi
3.2. Setting up the SCDE ..................................................................................................... 28
4. Implementing CDF at IST ............................................................................................ 30
4.1. IST – CDF Laboratory Capabilities ................................................................................ 30
4.1.1. CDF Hardware ..................................................................................................... 30
4.1.2. CDF Software ....................................................................................................... 30
4.1.3. CDF layout ........................................................................................................... 32
4.1.4. CDF Equipment Acquisition ................................................................................. 33
5. Development of SCDE ................................................................................................. 34
5.1. Commentary and Changes Tracking ............................................................................ 34
6. Aircargo Challenge – Application Project ..................................................................... 37
6.1. Calculation Model ...................................................................................................... 37
6.2. Domains ...................................................................................................................... 41
6.2.1. Aerodynamics ...................................................................................................... 43
6.2.2. Propulsion ........................................................................................................... 45
6.2.3. Avionics ............................................................................................................... 46
6.2.4. Weight and Structure .......................................................................................... 47
6.2.5. Air Conditions, Costs and Requirements ............................................................. 48
6.2.6. Assembly and Presentation ................................................................................. 48
6.3. Procedure ................................................................................................................... 52
6.4. Validation ................................................................................................................... 52
6.5. Discussion ................................................................................................................... 56
7. Conclusion ................................................................................................................. 58
8. Future ........................................................................................................................ 60
9. Bibliography ............................................................................................................... 61
Annexes ............................................................................................................................ 64
Annex A - Student Concurrent Design Environment Portuguese User Manual ...................... 65
A.1. Introdução .................................................................................................................. 65
Annex B – Appendix to the Student Concurrent Design Environment English Manual .......... 84
Annex C – JavaFoil ............................................................................................................. 91
Annex D – JavaProp ........................................................................................................... 92
Annex E – Macro VBA Functions List Created ...................................................................... 93
vii
Index of Figures
Figure 1.1– Example of design changes as a function of time. More design changes at the
beginning of the process allows for a lower number of total design changes. .............................. 2
Figure 1.2 – Life-cycle cost as a function of the product development phase. Black represents
the expected total life cycle cost along the development of a product, which is closer to
concurrent engineering prediction. Blue represents the expected traditional approach cost
evolution, but the real product development cost is represented in red........................................ 3
Figure 2.1 – Conceptual model of mission and spacecraft design process of ESA-CDF [6]. ....... 8
Figure 2.2 – Iterative process, the spiral model [6]. ...................................................................... 9
Figure 2.3 – ESA CDF Model architecture [1]. ............................................................................ 10
Figure 2.4 – ESA CDF layout [37]. .............................................................................................. 11
Figure 2.5 – Main design room layout [6]. ................................................................................... 12
Figure 2.6 – iCDF access architecture [7]. .................................................................................. 15
Figure 2.7 – Graphical representation of OCDS [11]. ................................................................. 16
Figure 2.8 – IMDC facility layout [2]. ........................................................................................... 21
Figure 2.9 – CDC facility layout [35]. ........................................................................................... 23
Figure 3.1 – Workbook concept of SCDE. .................................................................................. 24
Figure 3.2 – Worksheet concept of SCDE. ................................................................................. 25
Figure 3.3 – Post a parameter request form. .............................................................................. 25
Figure 3.4 – Update data exchange version form. ...................................................................... 26
Figure 3.5 – Insert Parameters Button. ....................................................................................... 26
Figure 3.6 – Subsystem Selection form, to parameter insert. ..................................................... 27
Figure 3.7 – Selection of parameter to insert. ............................................................................. 28
Figure 4.1– Ideal layout for the main room in a concurrent design facility [6]. ............................ 32
Figure 4.2 – IST-CDF main room layout. .................................................................................... 33
Figure 5.1 – Comment add button............................................................................................... 34
Figure 5.2 – Insert Comment/Change menu. .............................................................................. 35
Figure 5.3 – Insert User Name menu. ......................................................................................... 35
Figure 5.4 – Delete comment button. .......................................................................................... 36
Figure 5.5 – Delete Comment menu. .......................................................................................... 36
viii
Figure 6.1 – Take-off distance. .................................................................................................... 38
Figure 6.2 – Forces acting on an aircraft during ground roll. ...................................................... 39
Figure 6.3 – System architecture - Specific domains, aggregations, and external tools. ........... 43
Figure 6.4 – Wing design command button. ............................................................................... 43
Figure 6.5 – Open Java Foil menu. ............................................................................................. 44
Figure 6.6 – Wing creator button. ................................................................................................ 44
Figure 6.7 – Propeller design button. .......................................................................................... 45
Figure 6.8 – Open Java Prop menu. ........................................................................................... 45
Figure 6.9 – Calculation presentation model. .............................................................................. 49
Figure 6.10 – Presentations of the calculation results, if there is take off or not. ....................... 50
Figure 6.11 – List values function button. ................................................................................... 50
Figure 6.12 – Chart Creator Button. ............................................................................................ 50
Figure 6.13 – Graphic creator menu. .......................................................................................... 51
Figure 6.14 – Example of one project design evolution results chart. ........................................ 51
Figure 6.15 – Results of the first two iterations where the value of the wing span varies. ......... 54
Figure 6.16 – Comparing iterations 1 and 3, where the thrust value varies. .............................. 55
Figure 6.17 – Comparing iterations 3 and 4, where the defined CDo changed. ........................... 55
Figure 6.18 – Comparing Icaro and 2009 aircraft. ...................................................................... 56
Figure A.1 – Modelo geral do conceito SCDE. ........................................................................... 66
Figure A.2– Tipos de worksheet de um subsistema no SCDE. .................................................. 66
Figure A.3– Janela “Subsystem Selection”. ................................................................................ 70
Figure A.4– Janela “Select Parameters from selected/chosen Subsystem”. .............................. 71
Figure A.5– Janela “Post a Request”. ......................................................................................... 72
Figure A.6 – Janela “Insert Comment”. ....................................................................................... 73
Figure A.7 – Janela “Delete Comment”. ...................................................................................... 73
Figure A.8 – Janela “Update Data Exchange Version”. .............................................................. 75
Figure A.9 – Janela “Update Data Exchange”. ........................................................................... 76
Figure A.10 – Distância de descolagem. .................................................................................... 77
Figure A.11 – Forças a actuar na aeronave durante o rolamento na pista. ............................... 76
ix
Figure A.12 – Representação da existência ou não de descolagem.......................................... 81
Figure A.13– Janela “Show Graph”. ............................................................................................ 82
Figure A.14 – Exemplo de um gráfico de evolução das varáveis de projecto. ........................... 82
Figure B.1 – Take-off distance. ................................................................................................... 84
Figure B.2 – Forces acting on an aircraft during ground roll. ...................................................... 85
Figure B.3 – Presentations of the calculation results, if there is take off or not. ......................... 88
Figure B.4 – Menu “Show Graph”. .............................................................................................. 89
Figure B.5 – Example of one project design evolution results chart. .......................................... 89
Figure C.1 – JavaFoil program window. ...................................................................................... 91
Figure D.1 – JavaProp program window. .................................................................................... 92
x
Index of Tables
Table 2.1 – General tools used at ESA-CDF [6]. ........................................................................ 13
Table 2.2 – Domain specific tools used at ESA-CDF [6]. ........................................................... 14
Table 2.3 – Disciplines included in DET [2]. ................................................................................ 18
Table 2.4– Typical 4-day IMDC studies execution flow [2]. ........................................................ 19
Table 2.5– Disciplines tools currently used in IMDC [2]. ............................................................. 20
Table 4.1– General tools used in ESA-CDF versus the ones used in IST-CDF. ........................ 31
Table 4.2 – Domain specific tools used in ESA-CDF versus the ones used in IST-CDF. .......... 31
Table 6.1 – Workstations and their subsystems domains. .......................................................... 42
Table 6.2 – Inputs and Outputs for Aerodynamics domain. ........................................................ 45
Table 6.3 – Inputs and Outputs for Propulsion Domain. ............................................................. 46
Table 6.4 – Outputs for Avionics Domain. ................................................................................... 47
Table 6.5 – Inputs and Outputs for weight and structure domain. .............................................. 47
Table 6.6 – Inputs for assembly and presentation domain. ........................................................ 52
Table 6.7 – Variables values for Icaro aircraft. ............................................................................ 53
Table 6.8 – Assumed values for a first iteration in the project design of the aircraft of IST 2009
Team in the Aircargo Challenge. ................................................................................................. 53
Table 6.9 – Variables values already know to the 2009 aircraft. ................................................ 54
Table A.1– Descrição detalhada dos campos existentes para preenchimento numa worksheet
de “output”. .................................................................................................................................. 69
Table A.2– Descrição detalhada dos campos existentes para preenchimento numa worksheet
de “input”. .................................................................................................................................... 69
Table A.3– Subsistemas criados, associados à respectiva estação de trabalho. ...................... 80
Table A.4 – Variáveis dos subsistemas colocadas como “Inputs” e “Outputs”, pelos respectivos
subsistemas. ................................................................................................................................ 83
Table B.1– Workstations and their subsystems domains. .......................................................... 88
Table B.2 – Variables defined as “outputs” and “inputs” by each domain. ................................. 90
xi
Abbreviations
AOCS Attitude and Orbit Control System
APAE Portuguese Association of Aeronautics and Space
ASI Italian Space Agency
CDC Concept Design Center
CDF Concurrent Design Facility
CE Concurrent Engineering
CEF Concurrent Engineering Facility
CEI Central European Initiative
CESAR Central European Satellite for Advanced Research
CesaR Concurrent Engineering Set-up for Advanced Results
DET Discipline Engineering Teams
DLR German Aerospace Center
DMZ Demilitarized Zone
EADS European Aeronautic Defense and Space Company
ESA European Space Agency
ESTEC ESA Research and Technology Center
EXIX EXcel Information eXchange
GDCD Grid based Distributed Concurrent Design
GSFC Goddard Space Flight Center
iCDF Internet Concurrent Design Facility
IDC Integrated Design Capability
IDM Integrated Design Model
IMDC Integrated Mission Design Center
ISIS IMDC System for Information Sharing
ISS International Space Station
IST Instituto Superior Técnico
NASA National Aeronautics and Space Administration
OCDS Open Concurrent Design Server
RDL Reference Data Libraries
xii
SCDE Student Concurrent Design Environment
SSL Secure Socket Layer
UBI Beira Interior University
VPN Virtual Private Network
xiii
Index of Symbols
� Acceleration
� Aspect Ratio
� Wing Span
c Chord
�� Drag Coefficient
�� Lift Coefficient during Ground Roll
C� á� Maximum Lift Coefficient
�� Power Coefficient
�� Thrust Coefficient
� Drag
� Oswald Coefficient
�� Rolling Friction Force
�� External x Axe Forces
� Advanced Ratio
� Lift Induced Drag Coefficient
�� Lift Generated during Ground Roll
� Propeller Rotational Velocity
�� Propeller Efficiency
� Power
� Dynamic Pressure
Density
S Wing Loading
#� Ground Roll Distance
#$ Rotation Distance
#%& Take off Distance
' Rolling Friction Coefficient
T Thrust
)*+,-- Stall Speed
xiv
)%& Take off Speed
)%&.//0 Take off Speed Need
W Weight
2345+6 Empty Aircraft Weight
2%& Take off Weight
1
1. Introduction
1.1. Traditional Approach versus Concurrent Engineering
“One hand doesn´t always know what the other is doing.” 1
During several decades, products were developed with a process, which we can call the
traditional approach, where specialists from different subjects worked in different teams with
only one common objective, the final product. In this methodology each team designs a
subsystem in their own office or laboratory, relatively independent from the others, using stand-
alone tools. Design iterations at system level take then place in meetings at intervals of a few
weeks. It is a serial development method, where the product is first completely design by the
design engineering department, after which the manufacturing process is defined by the
manufacturing engineering department, and so on with all the teams involve on the project, re-
starting all the development process every time there is an adjustment, until the product is
completely established.
This has obvious advantages, such as the flexibility in the use of manpower resources and the
fact that it is a well-tried and routine process. On the other hand, it has drawbacks since it
favours certain isolation in the subsystem preliminary design, reducing the opportunity to find
interdisciplinary solutions and to create system awareness in the specialists. This creates a lack
of coordination and interaction among the different subsystems, and the teams only focus on
their own subsystems and not on the final product. This includes problems generated by how
their work is evaluated, many times just by their direct output and not for solutions that can
produce gains elsewhere. The workload demand on each team member, or even within each
team, is quite high due to the lack of interaction among different teams, because difficulties on
each of them might be overcome with a general and simpler solution if evaluate between all of
the teams. It is then very difficult, if not impossible, to re-assemble all of this knowledge, for
example to resume the study after some time with modified requirements. Also, the study client
was not necessarily involved in the total design process, significantly reducing the probability of
the design being fully satisfactory from the market point of view. Last but not least, the time
required for performing studies using the traditional approach (6-9 months in the case of space
probes) may be incompatible with today’s drive towards a shorter time-span from concept to
flight.
At the end of the last century the need for greater efficiency in designing new missions, lead
aerospace, automobile and other industries to a new concept. The traditional mission/product
design process was considered inefficient, as it was described above, because it required too
many meetings, the costs of the projects were increasing with the increased complexity of the
systems while the resources were reducing, took too long to be completed, and yielded
inconsistent results that did not meet the expectations. The constant world fastening evolution,
the need to build new and ambitious projects in a faster way, lead to the concurrent engineering
concept.
1 Anonymous Author
2
Concurrent engineering is not a quick fix for the company’s problems and it is not just a way to
improve engineering performance, it is a business strategy that addresses important company
resources. The major objective this business strategy aims to achieve is improved product
development performance. Concurrent engineering is a long-term strategy, and involves major
organizational and cultural change in any company, implying that it is not a trivial process to
apply.
In the traditional engineering approach a relatively short time is spent defining the product, and
a relatively long time is spent designing the product and, surprisingly, long time is often spent
redesigning the product during the production cycle. With all this excessively time spent in each
product, companies had to find a new development process, using a new concept. In the
concurrent engineering process tasks are done in parallel and together, by multidisciplinary
teams, and there is an early consideration for every aspect of the product’s development
process. It focuses on the optimization, distribution of the companies’ resources and the
satisfaction of the customer, in the design and development process to ensure that it is effective
and efficient.
Figure 1.1– Example of design changes as a function of time. More design changes at the beginning of the process allows for a lower number of total design changes.
The cost, as result of the number of design changes, is another important issue when
comparing the concurrent engineering with the traditional approach. In the traditional approach
the design changes increase at the beginning of production of a product, and so the costs
increase too, and in a dangerous way, probably exceeding the total life-cycle cost. On the other
hand, in a concurrent engineering approach the major design changes are preformed in the
concept design phase, which allow a better control of the costs, as illustrated in Figure 1.2.
3
Figure 1.2 – Life-cycle cost as a function of the product development phase. Black represents the expected total life cycle cost along the development of a product, which is closer to
concurrent engineering prediction. Blue represents the expected traditional approach cost evolution, but the real product development cost is represented in red.
The whole concurrent engineering approach could be explained by the following definition:
“Concurrent Engineering is a systematic approach to integrated product development that
emphasises the response to customer expectation. It embodies team values of cooperation,
trust and sharing, in such a manner that decision making is by consensus, involving all
perspective in parallel, from the beginning of the product life-cycle. [1].”
The implementation of concurrent engineering addresses three main aspects: people, process,
and technology. It involves major organizational changes because it requires the integration of
people, business methods and technology, and is dependent on cross-functional working and
team-work rather than the traditional hierarchical organization. One of the primary people issues
is the formation of the teams. Collaboration rather than individual effort is standard, and shared
information is the key to success. Team members must commit to working cross-functionally, be
collaborative, and constantly think and learn. The role of the leader is to supply the basic
foundation and support for change, rather than to tell the other team what to do. However,
concurrent engineering without leadership will have no clear direction, goal or plan, leading to
an unsuccessful design project, emphasizing to the importance of leadership in a product
development process. Finally, training addressed at getting people to work together in teams,
plays an important role in the successful implementation of concurrent engineering.
Concurrent engineering has direct advantages that can be recognized understanding the way it
works, such as, faster time design, lower development, manufacturing and production costs,
improved quality of the result product, increased efficiency and performance, higher reliability in
the product development process, increased effectiveness in transferring technology, increased
customer satisfaction, and the ability to recognize necessary design changes early in the
development process. It has also additional advantages implicit in the process such as the
4
increased innovation by having all players participating in the concept development phase, the
ability to execute high level and complex projects while minimizing the difficulties, the reduction
or elimination of the number of design changes and re-engineering efforts at later phases, and
the faster reaction time in responding to the rapidly changing market.
Over the time companies that started using the concurrent engineering methodology discovered
several critical issues to its correct implementation. Warning signs include lack of willingness to
institutionalize concurrent engineering, maintenance of the traditional functional reward system
and traditional report lines, lack of teamwork training, definition of unrealistic schedules, and a
focus on computerization rather than process improvement.
Concurrent engineering is currently used in many different companies and for many different
purposes. It is used in automotive companies, in the airplane industry, for plane development
and others such as ballistic systems by Boeing, and by the aerospace agencies to project space
missions and satellites. As a curiosity it has already been used by Polaroid Corporation in the
development of the Captiva instant camera and, as result of it, Polaroid was able to make
literally hundreds of working prototypes. This reveals the opening options provided by the
concurrent engineering approach.
1.2. The Aircargo Challenge Event
The Aircargo Challenge competition was first organized by APAE (Portuguese Association of
Aeronautics and Space), and was created to stimulate the aeronautics fields. It is aimed at
university students of Technological Sciences or Engineering. The 2009 competition is however
organized by the Association of Aeronautical Engineering of Beira Interior University (UBI).
In the competition, the team should design, build and fly a small aircraft controlled by radio to
take off with the maximum possible payload, in a landing strip with 60 metres of length. After
take off, the aircraft should fly over the field at least once and land in a place previously defined.
There are several aspects to take into account while designing the aircraft. The aircraft should
have a fixed wing to participate in the competition, the use of human help or other auxiliary
devices for take-off is forbidden, and the propulsion system should be only one, choose
between the lists of motors allowed in the competition [18].
1.3. Objectives and Motivation
The main objective of this thesis is to implement a concurrent design environment, using the
software provided by ESA, the Student Concurrent Design Environment (SCDE). The
implementation includes: suggestion for a possible layout for the concurrent design facility,
scaled down from the ESA Concurrent Design Facility (CDF), meeting the requirements of
available space and academic environment; the complete and correct installation of the SCDE;
and, the understanding and description of the system working process.
5
The other objective is to define and develop a model verifying the complete functionality of the
system, but having in mind the academic environment. Since the SCDE software provided by
ESA is focused on space mission design, the objective established is to model small aircrafts
design to compete in the Aircargo Challenge. This design should evaluate the possibility of
aircraft take-off, taking into account the payload present in the aircraft.
It is necessary to create all the system to be applied to the aircraft design and also some
knowledge management and other developments.
1.4. Thesis Outline
This thesis is divided in nine chapters plus a references section. After the introduction, Chapter
2 entitled “CDF in the World” will review the state of art, presenting some of the most important
concurrent engineering design facilities in the world, related to space missions.
Chapter 3 will briefly introduce the Student Concurrent Design Environment (SCDE), which is
the main tool to be implemented. Chapter 4 will discuss the issues referring to the laboratory
where the system was implemented, with focus on the layout issue, as well as the hardware
and software aspects.
After the implementation of the facility and system a new application was developed, as an
example of the system capabilities and also to test the system. In chapter 5 the general
developments to the system are presented followed by the specific developments to the new
application project in Chapter 6. This chapter also includes the explanation of the calculation
model for the aircraft design, the domains created to the specific project and several tests
results.
Conclusions, limitations of the study, and a general discussion of the work – constraints,
limitations, etc. – are developed in Chapter 7. The thesis ends with suggestions for further
research and for future studies.
6
2. CDF in the World
2.1. Introduction
Since concurrent engineering became a real project design method, two facilities stood out in
the space missions design. These are the European Space Agency Concurrent Design Facility
(ESA-CDF) and the National Aeronautics and Space Administration Integrated Mission Design
Center (NASA-IMDC), in Europe and in the United States of America, respectively.
The benefits demonstrated through this method were quickly transferred to other domains,
which resulted in the creation of a variety of companies using concurrent engineering to their
projects. It had a real integration in many actual applications to the society, from aviation to
space, from automobiles to a simple photograph camera. It has shown the whole benefits of
concurrent engineering.
2.2. ESA-CDF
2.2.1. Overview
In 1998, an experimental design facility was created in the ESA Research and Technology
Centre (ESTEC), to evaluate the benefits of the Concurrent Engineering and perform the
assessment of several missions. Initially conceived only for the assessment and the conceptual
design of future space missions, i.e. the pre-phase A, soon became available to all ESA
programs for interdisciplinary and inter-directorate applications, which could be based on
concurrent engineering methodology.
It is important to explain the meaning of the pre-phase A studies, which ESA performs several
each year, to understand the process at the Concurrent Design Facility (CDF). A pre-phase A is
an assessment study, with the purpose of assessing the feasibility of a new space mission from
the technical, programmatic and economic point of view. This is normally achieved by producing
a preliminary conceptual design of the mission and space system. The study results are used to
support the mission selection process. If the mission is accepted the study report is used as an
input to the industrial Phase-A design studies. In short, it is an initial study of the feasibility of
one future space mission. These studies are normally performed at the ESTEC, by technical-
support specialists [1].
The first case study was provided by the Central European Satellite for Advanced Research
(CEDAR) mission assessment, performed in the beginning of 1999, which ESA had undertaken
jointly with Italian Space Agency (ASI) and behalf of the Central European Initiative (CEI). Due
to this fact, the first name applied to the design facility was Concurrent Engineering Set-up for
Advanced Results (CedaR) [37].
7
The CDF infrastructure is based on the Integrated Design Model (IDM), an in-house develop
tool, which allows integration of all the subsystem disciplines tools and parameters in a
consistent and effective design environment.
2.2.2. Main objectives
The main goal associated with the CDF is improving the design process of future space
projects. Besides these projects, CDF has also hosted design sessions for European academic
institutions, targeted for student's space projects and for a more general training in concurrent
engineering. CDF is also a reference model for recent concurrent facilities in industry.
In early 2007, ESA reach the milestone of 70 assessment studies combined with 12 industrial
reviews. The studies have covered space science, astronomy and planetary exploration
missions, earth observations satellites, telecommunication satellites, International Space Station
(ISS) and human spaceflight activities, as well as launch and entry, or re-entry, vehicles [37].
When the experimental facility was set-up, besides the main goal, there were several objectives
ESA wanted to achieve [1]:
- Create an experimental mission design environment in which the conceptual design of
space missions could be performed in a more effective way.
- Apply the practice of CE to a number of test cases to identify the potential of such
approach in the various phases of space mission development.
- Gather the information needed to evaluate the resources required to create a
permanent facility available to all programs.
After an initial effort concentrated on the set-up and integration of the computers, used to host
the basic software, mainly consisting of office-automation products and specific engineering
tools, ESA focus on the selection of a case study that was initiated in the facility. Several
studies and tests were performed in order to prove the approach and measure its performance
on a real mission, and these results provided the requirements for the implementation of the first
prototype of the CDF.
The achieved quality results in short time revealed the value of such method, and the key
elements of this implementation were set as being the process, the multidisciplinary team, the
integrated design model, the facility, and the software infrastructure. These subjects are
described next.
2.2.3. CDF Organization
• Process
A space system has many interdependencies between components and, that implies that the
definition and evolution of each component has an impact on other components and that any
8
change will propagate through the system. This leads to the conceptual model of the design
process shown in Figure 2.1. To ensure that the design process converges on an optimised
solution is essential that an early assessment of the changes impact is made. This is the
intention of using CE.
Figure 2.1 – Conceptual model of mission and spacecraft design process of ESA-CDF [6].
A few meetings are preformed at the beginning of the process, with a restricted number of
specialists, including the customer, team leader and system engineer. These early meetings
intend to define and formalise the mission requirements, to define the constraints, to establish
design drivers, and to estimate the resources needed to achieve the study objectives.
After the early meetings the study starts and the design process is then conducted in a number
of sessions, however unlike the first meetings, all specialists must participate. This simultaneous
participation of all specialists reduces the risk of incorrect or conflicting design choices, as each
major decision is debated and decided together with all the participants. Thus, the disciplines
that were traditionally involved later in the process have the chance to participate from the
beginning and correct paths that could invalidate the design later. However, surrounding the
subsystem design there is an iterative process, which addresses all aspects of the system
design in a quick and complete way. The iteration process is demonstrated in Figure 2.2, called
the spiral model.
Usually 6 to 10 sessions are taken, with an approximate duration of 4 hours each, twice a week,
to perform a study assessment [6].
9
One key factor of this process is that customers have the possibility to discuss and correct in
real-time any orientation of the design not in line with their expectations, since they are always
invited to participate in all sessions along with others specialists of their choice. The first design
sessions starts with customers presenting the mission requirements, as well as the constraints
to the team.
Figure 2.2 – Iterative process, the spiral model [6].
Along the sessions preformed for each mission/product, each specialist presents the proposed
option for his/her domain, not disregarding the implications of the solution to the others
domains. The main goal between the iterations done, after discussion, is the ability to conduct a
process that is not dependent of the path followed. At any stage it must be possible to take
advantage of alternative paths or use professional estimates to ensure that the process is not
blocked by a lack of data or lack of decisions.
• Team
A place where a group of engineering specialists work together might amplify conflicts. Above
all, human resources are the most value and crucial element of concurrent engineering and, to
avoid conflicts, the group of specialists must work as one team. This is the fundamental part of
the Concurrent Engineering: create a motivated multidisciplinary team that performs the design
in real-time. There are several key factors to make it work:
- Acceptance of the new working method,
- intense and focused effort,
- co-operation,
- availability to perform design work and give answers at the same time,
- team spirit, and
- a clear and short term goal.
10
This might seem simple, but it is not. Engineers are under high pressure because they are
required to prepare the design of their sub-systems, follow the baseline discussion and identify
possible influences of other domains on their own, always be ready to answer questions related
to their domain, adapt their subsystem model anytime it is needed due to changes in the
baseline, and record all the design drivers and notes to perform a final report [1].
There are several disciplines involved in each study, and the choice of disciplines depends on
the detail level required and on the specialization of the available expertise. However, there is a
limit to the number of disciplines to avoid extended and unnecessary debates allowing the
design iterations to have a fast evolution. A position in the facility is created for each discipline,
assigning an expert in each particular domain and equipped with the necessary tools for design
modelling, calculations and data exchange.
• Model
In real-time process it is necessary a model that supports fast modifications and analysis of new
scenarios. This lead to a model-driven design process, using the information derived from the
collection and integration of the tools used by each domain.
Once all basic models are defined according to the mission/product scenario, they are
established before performing the iterative design process. Each model consists of an output,
input, calculation and result areas. Input and output areas are used to exchange parameters
between models, i. e. other domains, the calculation area contains equations and specification
data for each domain and the result area is used to summarize the numeric results of the
specific design for future presentation as well as to be used in the report at the end of the study.
The architecture model is shown in Figure 2.3.
Figure 2.3 – ESA CDF Model architecture [1].
11
• Facility
The design sessions take place in the Concurrent Design Facility. The CDF is a suite of rooms
designed and equipped with all the relevant hardware and software tools to create a
multidisciplinary design environment, providing effective communication, data interchange,
engineering tools and databases to a number of team members working [1].
The CDF consists of three design rooms and a number of support rooms grouped around a
central foyer, as shown in the Figure 2.4. The main design room with 30 computers is used as
the primary room for large mission or large instruments study, while the project design room is
smaller and is mainly used for smaller studies and reviews. The support design room is more a
conventional meeting room.
Figure 2.4 – ESA CDF layout [37].
The equipment location and the main design room layout, Figure 2.5, are designed to facilitate
the design process, the interaction, the co-operation and the involvement of the specialists. In
particular, the disciplines with the most frequent interaction or others affinities are located close
to each other.
12
Figure 2.5 – Main design room layout [6].
Each workstation is dedicated to a technical discipline. Most of the workstations have identical
PC’s but the configuration, structures and the simulations positions have specific and dedicated
workstations. All workstations contain a preview screen which can be used to pull data from the
projection wall or display additional data. Each workstation also has a camera and a
microphone to enable more inclusive experience for remote participants [1].
• Software infrastructure
Depending on the project design, tools may differ. However, the CDF at ESA, has already the
tools required to all space project designs. First, it is crucial to generate each model, propagate
data between models, create a documentation-support, and all the domain specific tools for
modeling and/or for complex calculations. It is also essential to define the storage and archive
capability. After that, is useful that the infrastructure also allows its users to work remotely from
any ESA centers, as well as an easily exchange of information and documentation between the
normal office working environment and the facility environment.
To create such infrastructure many tools are required, which suggest the company to choose
products already available at the office domain and at the technical domain. That was a solution
followed by ESA at CDF which, at the end, result in no additional licenses required for the major
software products to be employed.
The used of tools already existent at the company, allows a faster evolution due to the existing
skills of the team in each products.
At CDF, the system model selected was the Microsoft Excel ® spreadsheets, sustained by its
availability and again, the existing skills of the team. It was then decided to split the system
model into components that mirror the domains of expertise of the team members, allowing
work to be perform on the modeling independently and in parallel, and without the dependence
13
on a single modeling expert. This kind of model requires a mechanism to exchange the relevant
data between domains in a controlled manner. The problem is solved creating an exchange
workbook, to share all the data between domains. All this was made using the macro systems
available at excel.
The general tools chosen as basic infrastructure items, to be used by all team members, are
indentified at the Table 2.1.
Function Tools Used
System modelling Excel spreadsheets
Storage area for all data files NT file server
Project Documentation Microsoft Word
Electronic communication within the team LotusNote mail
Documentation Storage and Archive Terminal Server (TSE)
Remote audio/visual communication Video conferencing and Net meeting
Table 2.1 – General tools used at ESA-CDF [6].
The domain specific tools were also the already existents at ESA, brought by each expert
domain. The tools were integrated in the infrastructure of the facility, keeping the exchange
between them and the excel spreadsheets to the minimum, to avoid costs and delays incurred
due to the software development. If tools were also implemented in spreadsheets, the
interfacing was simple and even automated. However, there are domains that have applications
running in different workstations, and in those particular cases an interface was created to allow
results of specific calculations to be transfer and available at the excel model for additional
processing or propagation through the domains. The domain specific tools are defined at Table
2.2.
14
Domain Tools Used
Structural Design, Configuration and Accommodation
CATIA
AOCS – Attitude and Orbit Control System Matrix X, Matlab
Mission Analysis IMAT, STK, ORION, Swing-by Calculator
Mission Simulation and Visualization EUROSIM
Programmatics Microsoft Project
Cost Modelling and Estimation ECOM Cost/Technical database and Small
Satellite Cost Model, Race Model
Communications STK
Instruments MathCAD
Table 2.2 – Domain specific tools used at ESA-CDF [6].
All these tools are always subject to improvements, changes and new versions, that better
satisfy the experts of each domain, as well as new capabilities insert in the facility.
2.2.4. Developments in Progress
The techniques and tools developed at ESA-CDF through the time, are now well tuned and
established for the in-house application to the preliminary phases of the space project life-cycle.
Furthermore the know-how and the models developed in CDF have gained a lot of interest
among partners (agencies, industries and academia) in the last years.
Several ESA Institutional Partners requested the CDF base, the IDM, for the creation of their
own facilities. Therefore, several developments for CDF started to provide benefits to these
institutions by establishing a Centre of Excellence for Concurrent, Collaborative and Distributed
Engineering using open standards and common information models. The idea is to develop
these centers starting with a common and agreed data representation in order to facilitate future
interoperability and interchange, joint project work, link of their facilities for real-time
cooperative/concurrent engineering.
To be able to create a global E-collaborative environment for the design and development of
space missions, with all partners contributing to its improvement, there are three separate
activities currently ongoing: the iCDF (Internet CDF), the OCDS (Open Concurrent Design
Server), and the GDCD (Grid based Distributed Concurrent Design), that will be briefly explain
next.
15
• Internet CDF (iCDF)
The iCDF main function is to provide remote access connectivity by third-parties to the ESA
CDF via secure communications protocols over the internet, using dual-factor strong
authentication mechanisms based on digital certificates, passwords and secure protocols.
There will be an iCDF administrator who will be able to control and distribute third-party access
in a flexible and timely fashion according to the specific profile of the users and/or study
schedule.
Connected through the iCDF, the CDF external partners will be able to participate in the entire
design session remotely. They will also be able to edit documents as well as to see real-time
Data Exchange in the CDF. Using the Citrix publishing technology, it would be possible for them
to access any public domain information relevant for the study.
The connection access is sustained in a “trusted” demilitarized zone (DMZ), created
independent from the ESA Intranet. To connect to this zone the external partners will need to
enable a direct Secure Socket Layer (SSL) Virtual Private Network (VPN) connection with the
CDF’s SSL VPN appliance. At Figure 2.6 is shown the iCDF access architecture.
Figure 2.6 – iCDF access architecture [7].
• Open Concurrent Design Server (OCDS)
The OCDS activity involves the implementation of the transformation of the CDF concurrent
design model and the methodology into an Open Concurrent Design Server. The OCDS bridge
the current information towards standard information models and Reference Data Libraries
(RDL). Through the use of object model technology based on open standards for
interoperability, OCDS system intends to achieve a major quality and productivity
improvements. Besides that, these methods and technology are now available to the space
industry in the form of interoperable space information modeling objects using ISO norms, also
16
allowing automated standards checking and cost estimating to better control project scope,
schedule and cost. The Figure 2.7 shows a representation of OCDS.
The OCDS will include data models and RDLs readily available for the users to download
and/or consult.
Figure 2.7 – Graphical representation of OCDS [11].
• Grid Based Distributed Concurrent Design (GDCD)
A Grid-based infrastructure is an appropriate architecture to support distributed engineering. A
Grid could be seen as an organized network of computers which add up their own computing or
storage capabilities to achieve a common goal. A node of the Grid may be given the possibility
to split its own computational load and to distribute it to new computers which opens up the
possibility of computation trees with undefined depth thus matching very complex products. This
model is relevant in engineering as far as the work can be clearly split into independent tasks
forming a tree.
GDCD intends to study how to allow geographically distributed facilities to interact each other in
real-time over wide area networks adopting the Grid technology for the purpose of space
projects, to make the structure deployment consistent, cheap and compatible with Concurrent
Facilities.
This study isn’t only being done by ESA, but in collaboration with DATAMAT Company.
2.2.5. Why choose ESA-CDF
ESA-CDF plays an important role in the existent concurrent design facilities and was one of the
first to be implemented. It is an excellent design facility for space missions and is always in
active development.
ESA has created a student version of their own concurrent design facility, which intends to
develop a capable mentality in students designing mission or engineering projects. This version
is free and more user-friendly since the model was simplified.
17
Nowadays reducing cost, workload, and time expend is crucial to engineering project design,
and creating this kind of thinking in the students is advantageous. Understanding the concurrent
engineering model lead students to a more effective learning and preparation to the outside
professional work world. ESA contributes to this situation by providing the Student Concurrent
Design Environment, which will be the base of this study.
2.3. NASA – IMDC
2.3.1. Introduction
In the mid 1990’s, during a period of shrinking resources (money and labour) and the movement
towards greater efficiency, NASA (National Aeronautics and Space Administration) established
the IMDC (Integrated Mission Design Center) at the GSFC (Goddard Space Flight Center),
which is part of the IDC (Integrated Design Capability). The perception within the GSFC at the
time was that the traditional approach was inefficient, expensive and takes too long to complete.
The ‘new’ approach implemented by GSFC was modelled after the principles of collaborative
and concurrent design engineering, where study clients would closely collaborate with the
facility’s resident team of discipline engineers throughout the space mission study period.
Defining the new approach, there were two important features that were absent from the
traditional approach. The first one was the development of an integrated design center
laboratory to facilitate the mission design studies. The design center laboratory would
accommodate several workstations and servers capable of sharing information during a design
process. With a permanent office space, the study team could access a central location to
gather and develop the mission concepts in a focused and undisturbed environment. The
second feature involved the time and people assigned to the study. Once, at IMDC, the
engineers initiate a new study, the team members would work at full-time in the study until its
completion, even though they have other work assignments.
The four elements of the IMDC structure are people, process tolls and facility, and will be
discuss next.
2.3.2. IMDC People
The teams at IMDC are defined as Discipline Engineering Teams (DET) and are composed by
members which selection is based on their space flight experience, either in flight or supporting
ground system, and the ability to work in a collaborative, concurrent environment. Most of these
members have 10-15 years of experience designing subsystems for space flight missions, and
DET’s are one of the most important issues to concern in the design process at IMDC.
A DET has always a team lead and a system engineer, combined with other specialists. To
support the covered areas, actually at IMDC the disciplines included in DET are showed in
Table 2.
18
1 – Flight Dynamics and attitude control 9 – Mission operations and ground systems
2 – Propulsion and propellant 10 – Launch vehicle capability
3 – Command and data handling 11 – Reliability and safety
4 – Communications systems and RF links 12 – Mission cost estimation
5 – Flight software 13 – Mission risk analysis
6 – Solar array, battery, and power electronics 14 – Orbital debris and deorbit analysis
7 – Mechanical and structures 15 – Orbit environment assessment
8 – Thermal control 16 – Risk management
Table 2.3 – Disciplines included in DET [2].
2.3.3. IMDC Process
To perform a study methodology was organized based on three different phases: Preparation,
Execution, and Wrap-up.
The first challenge for each study is to establish the reasonable set of client expectations to be
met. The next is balancing the study requirements with IMDC study resources, in terms of
analysis and available labour. This is part of the first phase, the preparation, which starts when
the client completes an on-line ‘IDC Request for Support’ form, identifying general information
concerning the mission type, area of application for the study requested, and the schedule
expected. After a brief review of the request by the staff, there are several meetings scheduled
with the client, which are used to discuss study concerning issues, support issues, and to help
the client completing roughly 100 entries of a pre-work questionnaire. This questionnaire is
designed to retain detailed information on the science and mission objectives, instruments
concept, orbit parameters, pointing requirements, mission operational concept, and desired
study trades and products. This first phase can start 2 to 4 months before the second phase.
The second phase is called the Execution. Depending on the study scope, this phase typically
takes 4 to 5 days. The full study is conducted by the DET, led by the team leader and system
engineer. A typical 4-day IMDC study execution flow, or timetable, is shown on Table 2.4.
19
Day 1
AM
o Client briefing to IMDC team on mission and science objectives, and IMDC objectives.
o IMDC systems engineer briefs DET on pre-work results and engineering approach.
PM
o Coordination meeting with full IMDC DET and client team to review current baseline concepts, identify open issues, and schedule open splinter sessions.
o Client collaboration and mission design process.
Day 2 & 3
AM o Coordination meeting with IMDC and client teams. o Mission design process continues.
PM
o Coordination meeting with full IMDC DET and client team to review current baseline concepts, identify open issues, and schedule open splinter sessions.
o Client collaboration and mission design process.
Day 4
AM o IMDC DET complete final analysis, reviews final end-to-end conceptual design,
prepares final presentation package for delivery to client.
PM
o Final design study results presented to client team. o Action items resulting from client briefing are reviewed. o Short debriefing held with client. o DET begins close-out of action items and finalizes documentation.
Table 2.4– Typical 4-day IMDC studies execution flow [2].
The IMDC process, as a concurrent engineering process, is based on several iterations. These
iterations are repeated until all parameters converge into a coherent final mission concept
baseline design. The process enters its final phase, the Wrap-up phase, when this final baseline
design provides sufficient information to allow development of credible performance and cost
models with contingencies.
2.3.4. IMDC Tools
To meet client expectations, is crucial that IMDC has the best tools. There are two different
general categories in the tools IMDC uses, the infrastructures and the disciplines tools.
• Infrastructures tools
Infrastructures tools are typically unique, either developed at NASA for use by de IMDC team,
or developed in or for vary similar design centers. These types of tools directly support
concurrent engineering, such as the electronic data exchange interface platform, and are
perhaps the most important tools in the IMDC, because they keep the IMDC team coordinated
throughout the design. They are under the direct management of the System Engineer, assisted
by a team.
After using the traditional means as paper, email, a sophisticated data exchanged platform was
developed and put in use, the IMDC System for Information Sharing (ISIS). This tool developed
20
in html to be accessed via web browser, revealed a lack of flexibility inherent to any html
application. A new system level design tool and information platform was then created. It was
dubbed EXcel Information eXchange (EXIX) and was coded in Visual Basic to run under a
system of inter-accessible but separate Excel applications.
• Disciplines tools
Disciplines tools cover the tools provided by the discipline engineers and their home
organizations. They can be commercial tools or custom made. Frequently they are developed in
house, in many instances by the disciplines engineers for personal use. These are called DET
tools. A list of tools currently used by several DET’s in IMDC is presented in Table 2.5.
Flight Dynamics Power Subsystem
o Satellite Tool Kit o SWINGBY o GTDS o GMAN o MAnE o Custom Target Acquisition Tool o Freeflyer Engineer o Solar Cycle Modelling Tools o MatLab o Mathematica
o Electronic Power Spacecraft Simulation Tool
o Solar Power Modelling Tools o Orbit Dynamics Energy Balance Tool o Battery Sizing Tool o Voltage Trade Sheet o Radiator Degradation Tool
Mechanical / Structural RF Communications
o Ideas o Pro-E o Autocad o Pastran / Nastran o On-Line Launch Vehicle Selection Tools
o CLASS
Parametric Cost Analysis
o PRICE-H
Table 2.5– Disciplines tools currently used in IMDC [2].
All subsystem engineers perform maintenance, improvement, and upgrading, of their tools, with
a little or no central coordination from the IMDC.
2.3.5. IMDC Facility
The facility in a concurrent engineering process plays a critical role, as already stated, and
IMDC is not an exception. Occupying nearly 90 square meters, it contains 20 work areas, each
having a designated engineering workstation, with the necessary equipment, communication
capabilities and software. These equipment and software is set to provide the maximum
interaction between workstations, as well as the room itself is also designed to increase client
and study team interaction. In the laboratory there is a conference table centred in the front of
the room, occupied by the clients during the study, encouraging the client to maintain a
21
presence in the room so that the team can obtain quick feedback to questions and design
issues.
A layout of the IMDC facility is shown in Figure 2.8, where can be noticed the presence and
arrangement of the teams in the room, as well as the three projections screens on the bottom of
the layout, each one controlled individually, allowing different images in each one.
Figure 2.8 – IMDC facility layout [2].
A separate conference room provides space for pre-work sessions and meetings. This
conference room can also be used by the client during the study execution.
2.4. Other CE facilities
2.4.1. German Aerospace Center
At Bremen, in the Institute of Space Systems of the German Aerospace Center (DLR), existing
and future space systems are analysed and evaluated regarding technical, economic and socio-
political aspects. Therefore, the institute develops and utilizes computer aided methods for
evaluating space concepts regarding applicability, acceptance, feasibility, costs and benefits.
One of the desired future methods is the concurrent engineering. DLR plan to build a
Concurrent Engineering Facility (CEF) at Bremen, adopting it for system analysis and concept
studies on phase A-level. The use of modern tools and communications within the DLR, will be
the most important issues to get an efficiency concurrent engineering methodology.
The CEF will provide the opportunity to perform collective and simultaneous operations by
experts of many specializations, and will available for internal as well as for external utilization.
22
2.4.2. European Aeronautic Defense and Space Company (EADS)
In 2005, EADS inaugurates a design office, holding nearly 250 workplaces in about 4500
square meters, built on the concept of concurrent engineering, based on the use of digital
modelling tools.
This design office differs of the concurrent design facilities that have been stated in this
document because, by default, the work of the various EADS Space Transportation design
teams is done at different places throughout the company, networked in real time. All teams are
able to access the same database, as well as the main European industrial partners via “virtual
platforms”, allowing them to introduce the data associated with their respective work share.
The different technical departments work currently, gradually adding the results of their
respective work to the database, allowing that every department can view the progress of the
whole project.
This interaction between the different players involved and the design office built under
concurrent engineering methodology, turned possible to optimise design and manufacturing
cycles and thus to boost productivity of the company.
2.4.3. The Aerospace Corporation
With the increase of personal computers and the advent of powerful spreadsheets software in
the early 1990s, more practical interactive approaches to computer-aided conceptual spacecraft
design emerged. Supported by these developments, three aerospace engineers created The
Concept Design Center (CDC) at the Aerospace Corporation. Their work, for a year, was to
appropriately link new versions of spacecraft-subsystems spreadsheets models that were
developed by subsystem experts before, and create, with that, a fast-paced collaborative
spacecraft design, based on concurrent engineering.
Today, more than 100 aerospace engineers participate on CDC teams, working in two
dedicated facilities (unclassified and classified). The main teams under the CDC Office, which
coordinates the center’s activities, are six [35]:
• Space Segment Team, the original CDC team, focuses on the space vehicle segment.
Each member designs a particular spacecraft subsystem and specifies the elements at
the part level. Computer-aided-drawings layouts are used to visualize physical
relationships among the subsystems.
• System Architecture Team considers all of the space-system segments (space,
ground, and launch). The level of detail does not extend below top-level descriptions of
each segment and their interactions – the minimum needed to understand the broad
architecture trades.
• Communications Payload Team focuses on communications subsystems at the part
level.
23
• Ground Systems Team examines elements of the group segment of space system,
including facilities, staffing, software, communications, and processing equipment.
• Kinetic Energy Weapons Team performs top-level design of space-based ballistic-
missile interceptors. The team is similar to the Space Segment Team but uses a
different set of performance metrics and technologies.
• Space Maneuver Vehicle Team is also similar to the Space Segment Team but
focuses on the requirements of launch, orbital preparations, re-entry, and reuse.
The design sessions take place in a dedicated facility, which layout is shown on Figure 2.9. The
configuration of workstations promotes face-to-face interaction between team members. The
customer team sits at the center table. Overhead projectors can display any team member’s
monitor. There are also several video teleconferencing cameras in the room, located at the front
and back walls [3].
Figure 2.9 – CDC facility layout [35].
CDC has become an essential part of the systems engineering that Aerospace provides. Six
teams currently perform a total of about 12 to 18 conceptual studies per year, leading the CDC
to become self-supporting, with most of the funds coming directly from customers studies [35].
24
3. The SCDE System
As told in chapter 2.2.5, the Student Concurrent Design Environment (SCDE) will be the base of
this study. The tool provided by ESA-CDF reveals a number of project solutions, allowing the
project to be based on space issues or not. This system also works based on the Microsoft
Excel ® worksheets.
The set up of the system is briefly explained in the next chapters, but an exhaustive installation
Portuguese manual can be found in Annex A.
3.1. The Model
Before starting developing the software, a model concept understanding is required.
As explained before, the base model essentially consists of two types of Excel workbooks, the
Data Exchange (server workbook) and the subsystems workbooks (Figure 3.1). In the server
workbook all the parameters need by other subsystems are stored, and the subsystem
workbooks contain all the information and tools needed for each one come to a good subsystem
design. There is also another workbook called Parameters whose function is to store all the
requests made by each of the subsystem domains.
Figure 3.1 – Workbook concept of SCDE.
The subsystems workbooks are divided in three main types of worksheets: input/output,
requests and calculations. Others may exist, but these three are the essential ones (Figure 3.2).
25
Figure 3.2 – Worksheet concept of SCDE.
All the parameters of the subsystem design are collected in the output worksheet, requested by
other subsystem domains. The input worksheet function is to obtain the parameters needed
from the data exchange workbook. Regarding the requests worksheet, there are two different
worksheets, the “requests for me” and the “requests by me”. Both are used to control the
requests of data made to another subsystem, and in the last one showing if the request data is
already available. In the Figure 3.3 the menu to post a request is shown. Finally, to perform all
the calculations need the calculations worksheets are used, as well as to store hardware data or
input parameters from external tools.
Figure 3.3 – Post a parameter request form.
26
The system is not instantaneous updated. After completed all the requests, the system needs to
inform all the subsystem. That is done, via the data exchange workbook, once the update is
complete, and a new iteration step is reached (Figure 3.4) .
Figure 3.4 – Update data exchange version form.
It is important to understand the version numbers which represents the design project along the
iteration steps. The version number is composed of three digits. The first indicates the design
concept model applicable (New Issue in the Figure 3.4). The design model number allows more
than one design concept to be worked out in parallel, if the project design need it so. Then after
the dot, there are two digits indicating the iteration step, which increases each time the model is
updated (New Version in the Figure 3.4).
At this point, all the requests were communicated and the data, if already available, will be
inserted in the output worksheet, and then again, available in the next iteration step. There is a
function to insert data from others subsystem.
Figure 3.5 – Insert Parameters Button.
After pressing the button shown at the Figure 3.5, the function will open first one menu, to select
the subsystem from which the user needs the parameter. This button exists at the worksheet
“Inputs” of each subsystem workbook. The menu is shown at the Figure 3.6.
27
Figure 3.6 – Subsystem Selection form, to parameter insert.
Once the subsystem is selected, the user just needs to select the parameter from the list (Figure
3.7) and define the line where the parameter will be placed in the worksheet “Inputs”.
28
Figure 3.7 – Selection of parameter to insert.
3.2. Setting up the SCDE
First, the system had to be installed in the workstations available. There were several errors,
during the installation process that delayed the work progress and should be referenced for
faster future installations. The first error found was the inoperability of the system using a
Portuguese version of Microsoft Excel ®, returning several errors and warnings in the visual
basic macros code. After having all the workstations using an English version of excel, it has
been noticed that some machines still not worked. The solution was found installing the ultimate
updates to the Microsoft Office ® through the internet.
Once the computers are linked in a network environment a central place which will store all the
workbooks in the same directory, including the subsystems, data exchange and parameters,
should be defined. Each domain computer will access the central place to open its own
subsystem workbook.
An effective concurrent engineering design is accomplished when several design domains are
working in close cooperation. It is essentially to first set the necessary subsystem domains for
each project and informing the system-engineering domain.
29
The system-engineering domain is not mandatory. However it is highly recommended in
projects with a large number of subsystems, like space mission designs. This domain is
responsible for summarizing the total design (requirements, budgets, administrative tools, and
others). The system domain engineer would be responsible for the control and update of the
data exchange workbook.
30
4. Implementing CDF at IST
The implementation of the concurrent engineering student environment at IST includes the
conception of a concurrent design facility, scaled down from the ESA CDF, meeting the
requirements of space and academic environment.
The first step to set up the facility is to link several computers acquiring a network environment,
as explained in the chapter 3.2. The necessary hardware and the available one, is explain next
in the chapter 4.1.1. Then, in the chapter 4.1.2 the software needed for each subsystem domain
is listed.
Once all the computers are ready, and with the system working, it is extremely important to
define the arrangement of the workstations in the room. This is one of the most important items
in a concurrent engineering environment, the layout facility, and is clarified in chapter 4.1.3.
4.1. IST – CDF Laboratory Capabilities
4.1.1. CDF Hardware
To perform a complex study it is necessary a certain number of workstations, to accommodate
each discipline. Typically at ESA-CDF there are 16 to 18 disciplines, most of them with two
dedicated workstations. An IST-CDF that could not be achieved, because the room is smaller
and there are currently only five computers available. Hence, each workstation may have to
serve more than one discipline, depending on the project. One of these computers will also
work as a server, to the other workstations.
Each machine is powerful enough to perform a study, using the necessary tools according to
discipline. However, communications is essential to the sessions, and supply the computers
with cameras and headphones could improve this aspect, especially when thinking about the
possibility of remote teams, as happens at ESA-CDF (in the Netherlands), where people from
ESOC (in Germany) often participate in the session.
It is also essential to have a multimedia wall to present the results. That could be achieved with
the inclusion of a projector, and perhaps a “Smart Board®” to perform analysis for whole team.
4.1.2. CDF Software
At IST-CDF there are several limitations with the software to use in the laboratory. Analyzing the
software used at the ESA-CDF there are programs that cannot be used at IST-CDF because
there are no licenses available. Thus, the solutions available at IST to use in concurrent
engineering studies, comparing with the general tools used in ESA, are presented in Table 4.1,
considering the restrictions existents from the budget and availability.
31
Function Tool used by ESA-CDF Tool used by IST-CDF
System modeling Excel spreadsheets Excel spreadsheets
Storage for all data NT file server WS1 Hard disk
Project documentation Microsoft Word Microsoft Word
Electronic communications
within the team Lotus Notes Not Defined
Documentation storage for
and archive Terminal Server (TSE) WS1 Hard Disk
Remote audio/visual
communication
Video-conferencing and net meeting
Not Defined
Table 4.1– General tools used in ESA-CDF versus the ones used in IST-CDF.
Besides the general tools, that are used to keep the concurrent design facility working, there are
the specific tools for each domain. The comparison is shown in Table 4.2.
Domain Tool used by ESA-CDF Tool used by IST-CDF
Structural design,
configuration,
accommodation
CATIA SolidWorks
AOCS Matrix X, Matlab Matlab
Mission Analysis IMAT, STK, ORION, Swing-
by-calculator STK
Mission Simulation and
visualization EUROSIM STK
Programmatics MS Project MS Project
Cost modeling and
estimation
ECOM Cost/Technical Database and Small Satellite
Cost Model, Race Model Not Defined
Communications STK STK
Instruments MathCAD Not Defined
Table 4.2 – Domain specific tools used in ESA-CDF versus the ones used in IST-CDF.
Referring to the specific tools, the STK program will be available soon in the laboratory, which
will be a huge advantage to space mission analysis throughout the concurrent engineering
design method.
32
4.1.3. CDF layout
The layout of a concurrent engineering facility plays an important role in the process. After
analyzing the layouts of the most important concurrent design facilities, an optimal layout was
determined, focusing the provision of the workstations in the room, the communications
between them, and the presentation of results. This is shown in Figure 4.1, is the ESA CDF
layout, where all the issues were taken into account in the main room.
Figure 4.1– Ideal layout for the main room in a concurrent design facility [6].
According to the room available for the laboratory in the IST, that layout is completely
impossible, as well as the number of workstations available for the studies. Hence, a layout was
created (Figure 4.2), which better serves the needs for a study using concurrent engineering
tools given the current available space restrictions. The multimedia wall must be movable since
it is in front of the main service door of the laboratory, where larger instruments must enter, if
necessary (the laboratory is a multi-purpose and space have to be shared between different
projects and goals).
33
Figure 4.2 – IST-CDF main room layout.
There is also a secondary room in the IST-CDF, with two workstations that could be used to
perform meetings between the client and the team, to discuss the main study issues and
objectives, etc. If necessary, they can remotely participate in the study, provided that cameras
and communications become available.
4.1.4. CDF Equipment Acquisition
Besides the communication system and the smart-board already referred, also acquiring also a
dedicated server to archive data would be worth, because currently it is being archived at one of
the workstations available, used by the domains.
If and when a new bigger place to set up the concurrent design facility becomes available, it
would be essential to acquire several new computers, ensuring that domain would not share
hardware.
34
5. Development of SCDE
After put into operation the SCDE at the IST, regarding to the room layout as well as to the
hardware and software needs, it is important to test the SCDE, analyzing and defining
improvements to do to it.
Testing the SCDE tool has to take into account the engineer work and the costumers view.
From the engineers point of view it is essential that the tool can record the developments and
evolution steps during the project design, for future reference. On the other hand, from the
costumer point of view, it would be worth that analyzing the developments done, could
understand the current status of the project design.
Therefore, finding some way to record the progress achieved, creating a knowledge base,
would solve the issue explained before. That will be explained in the next chapter.
Several other developments were done in function of the air cargo application project, which will
be explained in the chapter 6, reserved for that issue.
All the developments done in the Microsoft Excel® workbooks were done using the macros
visual basic programming language, with the Microsoft Visual Basic Editor 6.5 ®.
5.1. Commentary and Changes Tracking
As told before, doing a knowledge base tracking changes and comments is really useful for
future reference during the project design and for future projects.
Therefore, a function to register the comments and changes through the project was created.
This function allows the engineers to add their comments to a list, presented at the worksheet
“Administration” of their own subsystem workbook. To add anything to the list there is a button
(Figure 5.1) in each worksheet of all subsystems workbooks.
Figure 5.1 – Comment add button.
The list of comments and changes tracking, at the worksheet “Administration” of each
subsystem workbook, includes:
- Date;
- Responsible Name;
- Sheet Name;
- Change, Comment Description;
- Type, and;
- Keywords.
35
The date is automatically defined when a new entry is added to the table, as well as the
worksheet name from which it comes. The description and keywords are totally added by the
engineer, and the type of entry is chosen among the options available at the menu. The menu is
shown in the Figure 5.2.
Figure 5.2 – Insert Comment/Change menu.
For the responsible name, there is a special function created. Once an engineer starts using a
subsystem workbook, should define the name of the responsible at the worksheet
“Administration”. However, since that sometimes could be forgotten, before adding the first
comment/change to the list, it is requested that the name of the responsible is defined.
Figure 5.3 – Insert User Name menu.
36
That user name is inserted using the menu shown in the Figure 5.3, and it is strictly necessary
to insert a name and it should be longer than two characters.
However, to avoid the lost of essential data, these comments and changes inserted, are also
added to an external workbook named “Comments_Changes_Tracking.xls” present at the same
folder like the other system files. Inserted in this list are the aspects referred above plus one
column referring the name of the subsystem workbook from which the comment/change is
inserted.
It is also possible to erase an entry in the list present at the worksheet administration, using the
button shown in Figure 5.4.
Figure 5.4 – Delete comment button.
This button enables a function that analyzes the list of comment/changes and returns a list box
in the menu (Figure 5.5) with the lines in which there is a comment. After the selection of the
line, pressing the delete button will erase the comment and reformulate the table.
Figure 5.5 – Delete Comment menu.
It is important to notice that this erasing function only delete the entries present in the list at the
worksheet “Administration” of the subsystem workbook in use. It will not erase any entry in the
external list at the file “Comments_Changes_Tracking.xls”. This will avoid the lost of important
and significant data, by mistake.
The functions explained before intend to be simple and easy otherwise users will not use them
as frequently as desired. The functions also intend to be as automated as possible, to reduce
the users’ involvement, increasing their focus on the project and not on secondary issues.
37
6. Aircargo Challenge – Application Project
Throughout this thesis it has been affirmed that concurrent engineering design facilities have an
enormous versatility. The best way to demonstrate this is designing a project, using the SCDE,
different from a space mission design.
The Aircargo Challenge showed to be an excellent choice. It has everything needed to
demonstrate the efficiency of the concurrent engineering design method: several different
domains, several applications required for each domain, a clearly defined objective, and a
project allowing several students to work on it at the same time. It is a competition with students
involved in different years being a good test bed for the knowledge management functions.
The main purpose of the Aircargo competition is to design and build an airplane controlled by
radio that should take-off with the maximum weight possible, respecting several rules.
It is forbidden the participation of aircrafts that:
- Work by fluctuation of gases lighter than air (dirigible and balloons);
- Produce sustainability by rotary wings (helicopters and auto gyros);
- Have any kind of additional or auxiliary propulsion other than the motor choose from the
list of allowed motors;
- Use auxiliary devices during the take-off that don’t belong to the aircraft (including
human help) and that aren’t physically connected to the plane when it lands;
- Use metal propellers;
- The aircraft dimensions are limited by its total lifting surface. This area is limited to
A=0,70 m2.
The motor list changed throughout the past challenges. Currently only an electric engine is
allowed. However, some tests have been done with combustion engines, as will be shown. The
propulsion system is easily changed by the propulsion domain engineer.
The objective of the design and construction is to take-off the maximum weight possible in a
track length limited to 60 meters.
6.1. Calculation Model
In this chapter it is explained the approaching mathematical modeling of the airplane take-off, to
be used in the Aircargo Challenge. At this point it will be assumed that the aerodynamics
surfaces have been designed by the aerodynamics engineers’ domain, as well as the engine
have been selected by propulsion engineer’s domain. The specific domains will be explained in
the next chapter. These assumptions are extremely important to provide essential parameters,
such as weight (W ), wing area (S ), thrust (T ), maximum lift coefficient (C� á�) and others.
38
Fundamentally the take-off flight phase consists of accelerating from rest to take-off velocity,
)%&, and climbing to an altitude, which is greater than a reference obstacle height. The total
distance required to accomplish this is the take-off distance, #%&. However, in this project it will
be assumed that after reaching the take-off velocity, the airplane won’t have to climb to specific
altitude. Therefore, the take-off will be divided into two different parts: ground-roll and rotation
(Figure 6.1).
Figure 6.1 – Take-off distance.
The ground roll distance is designated #� , and is the portion where the airplane goes from rest
to )%&. The rotation distance #$ is the portion in which the airplane performs the rotation
maneuver, pitching up to increase the angle of attack.
The total take-off distance will be the sum of these two quantities
#%& 7 #� 8 #$ .... (6.1) The take-off velocity is calculated through the stall speed, )*+,--, which is affected by the wing
loading, and is defined as, [29]:
)*+,-- 7 :;<
=> ?@AáB
CDE. (6.2)
Thus, the velocity required for take-off is
)%&.//0 7 1,2)*+,-- 7 1,2 :;<
=> ?@AáB
CDE. (6.3)
• Ground Roll Distance
It is in this portion that the aircraft goes from rest, to take-off velocity. Therefore, the ground
distance must be evaluated by the acceleration
#� 7 I JK,L M) 7 N
= I OKEO,
KPQ.//0RKPQ.//0R (6.4)
with the acceleration, [29], found from
� 7 S;PQ
∑ �� 7 S;PQ UV W � W ��X (6.5)
39
where �� is the rolling friction force, given by
�� 7 'Y2%& W ��Z. (6.6)
Figure 6.2 shows a schematic that indicates the forces acting on an aircraft during ground roll.
The rolling friction coefficient, ', varies with the runway, ' [ Y0,04; 0,08Z [5]. �� is the lift
generated during ground roll, and is based on an enhanced lift configuration for the wing, as
well as the angle attack produced when the aircraft is on the ground.
�� 7 �`��, (6.7)
where q is the dynamic pressure,
� 7 > KE= . (6.8)
Figure 6.2 – Forces acting on an aircraft during ground roll.
Regarding the drag force (6.9), it is based on the drag coefficient, ��, and the ground-roll lift
coefficient , ��.
� 7 �� 8 � ��=. (6.9)
To evaluate the ground distance, using (6.4), it has to be assume first that T/W is constant,
otherwise it would only be calculated if the integral is solved numerically by taking small velocity
time steps, where T/W is actually constant and equal to the maximum thrust at each upper time-
step value of velocity.
Then assuming, that T/W is constant, the acceleration results in
� 7 bN 8 b=)=, (6.10)
where
bN 7 c J %; W 'L (6.11)
and
b= 7 S >=Jd
e L f' �� W ��R W � ��g. (6.12)
40
Then:
#� 7 I hKE�Di�EKE
KPQ.//0R 7 N= �E j� k�Di�E KPQ.//0
E�D l. (6.13)
• Rotation Distance
In this portion of the take-off, the aircraft angle of attack is increase until � 7 0,8�AáB. As a
convention, this is assumed to take three seconds. Therefore, since the velocity of the aircraft at
this point is )%&,
#$ 7 3)%&. (6.14)
However, since the resulted value is extremely high the rotation distance was defined to be #$ =
2 m.
• Take- Off Velocity
Equation (6.3), defines the required take-off velocity for the aircraft. However, it might be useful,
having the track length, to calculate the speed reached at the end of the track.
Therefore, at this chapter it is assumed that the aircraft will take the entire track to take-off,
maximizing the weight that it is capable of transport.
From (6.13), it is possible to give the take-off velocity versus the take-off distance, and with a
constant value for thrust:
)%& 7 n�D�E
o�=�E*� W 1p . (6.15)
This take-off velocity value, allows the engineer to compare, at the end of the track, if the
aircraft has the required speed, calculated with (6.3), basically if the aircraft take-off with the
selected weight.
• Required Thrust
As well as it is possible to determine the take-off velocity, knowing the track length and the
available thrust, it is possible to calculate the required thrust to reach the take-off velocity at the
limit of the available track.
Using again (6.13) and (6.11), to get the thrust value, it results in
V 7 k)%&= b= NfqErEs�tNgS 8 'l 2. (6.16)
This calculation result can be used to identify if the propulsion system is efficient for the weight,
or even to know the thrust required and then choose the propulsion system.
41
However choosing the propulsion system, through the value of the thrust, requires several other
parameters, such as the thrust coefficient, �%, and the power coefficient, ��, that are specific
characteristics of the selected propeller:
�% 7 %>uE�v , (6.17) �� 7 �
>uw�x , (6.18)
where n is the propeller rotational velocity, D is the propeller diameter, and P the power
transmitted from the motor.
The equation of the propeller efficiency is
�� 7 %{|}*+ �~�q| &}+5}+<{,�+ �~�q| �u5}+ 7 %K
� , (6.19)
where V, is the true airspeed, and the equation of the advanced ratio is
� 7 Ku�, (6.20)
which combined gives the thrust expression:
V 7 �u�
?P?� . (6.21)
On the other hand, at the next chapter, at the propulsion domain will be presented an easy way
to determine both the coefficients and the thrust.
6.2. Domains
Defining the most important domains to project design using concurrent engineering tools is an
essential issue for a good start. As a result, after determine the mathematical calculation model,
is now time to define which domains should be present at the Aircargo Challenge project.
Therefore, looking to the mathematical model is essential to have domains responsible for
several areas. For start, should have aerodynamics, avionics and propulsion domains to define
the base of the project. After that, all these items must be considered to the weight domain, as
well as to the structure domain, to reach a solid and economic solution based on the solutions
choose at the beginning domains. All these, leads us to a cost control and evaluation, as well as
verifying if project requirements are respected. Last but not least, the assembly of all the
configurations and the presentation of the results leads the project to a visual level.
Since, at the IST-CDF there are only five computers available to a project design, it is
impossible to assign a workstation to each of the domains referred before. Then, the solution
found to cover all these items is to aggregate some domains at the same workstation. The
Table 6.1 shows the solution found to cover all the essential issues.
The specific division was achieved in order to insure that specific domains, such as
aerodynamics, avionics, propulsion and weight & structures, have enough space and time to
work with their own specific tools. These domains, will have most of their work done outside the
42
excel subsystem workbook, and would be confuse to work with several different tools, defining
different domains.
However, the solution found, leaves also a big workload to the workstation 1 engineers
(probably, if defined, the system engineers), but is essential, since it is strictly need to
aggregate domains, that all these domains be together, because, it is the system engineer that
defines the project requirements, take control of the cost issues, and keeps the server updated.
It is essential to notice that, any subsystem domain should be able to present their own results
on the projection wall, but since probably there will be one projector at each project design
session, it is more intuitive that the system engineer could select the issues to present at each
time.
Workstation 1
Server
Requirements, Costs & Air Conditions
Assembly & Presentation
Workstation 2 Aerodynamics
Workstation 3 Avionics
Workstation 4 Propulsion
Workstation 5 Weight & Structure
Table 6.1 – Workstations and their subsystems domains.
It is also essential to define the system architecture, to understand the flowing of the project
design. The way the specific domains were presented before, already shows a possible
configuration. However, it is more perceptible with the Figure 6.3 where it can be also noticed
the external programs used by each subsystem as well as the domain aggregations done. Each
specific aggregation domain will be explained next.
43
Figure 6.3 – System architecture - Specific domains, aggregations, and external tools.
6.2.1. Aerodynamics
This domain purpose is to define all the aerodynamics issues related to the project of the
aircraft. This includes the wing profile selection and analysis, the reference area of the aircraft
calculation, as well as the calculation of the coefficients values, such as lift coefficient, drag
coefficient and others.
To perform these calculations, first the engineer access a tool denominated “JavaFoil” [15],
using the available command button (Figure 6.4) existent at the calculation worksheet at the
domain workbook.
Figure 6.4 – Wing design command button.
The “JavaFoil” is a java tool, available at the internet, which allows users to create any wing
profile wished, as well as to study the behavior of the wing through an aerodynamic flow. This
was the chosen tool because, first of all, it is free to use and because it works efficiently and is
very user-friendly. It also allows the user to save the wing coordinates in a file, and that, if
necessary, could be open by excel. It is not mandatory the use of this tool to perform the
44
aerodynamics design. This is the only option already available, but users can work with any
other tool.
After clicking the button the function will open a window warning the engineer of the next steps
(Figure 6.5).
Figure 6.5 – Open Java Foil menu.
Once all the input data to create the wing is defined, the tool generates the wing based on its
coordinates. The tool allows the user to copy this coordinates as text, which is really useful if
engineers intend to work with the wing data outside the JavaFoil. In order to facilitate the use of
that coordinates by excel, a strategy was developed, to simply generate the wing in excel and to
save the coordinates in a specific worksheet, by clicking in one button. Therefore, it is assumed
that the engineer click at JavaFoil to copy the text, by clicking in the button “Create Wing” at the
aerodynamics workbook, Figure 6.6, excel will copy the coordinate’s values to the worksheet
and generate a chart with the wing shape.
Figure 6.6 – Wing creator button.
At this book several particular calculations are preformed, in order to obtain the lift induced drag
coefficient, and the aspect ratio.
� 7 �E< , (6.22)
� 7 N��q, (6.23)
Equation (6.22) shows the aspect ratio obtained from the wing span and from reference area.
The (6.23) shows the lift induced drag coefficient, where e is the Oswald coefficient.
The inputs and outputs from others subsystems for this subsystem workbook, are presented at
Table 6.2.
45
Inputs Outputs
• Density (ρ)
• Maximum Lift Coefficient (�AáB)
• Reference Area (S)
• Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (')
• Lift induced drag coefficient (k)
• Ground Lift Coefficient (��)
• Chord (c)
• Wing Span (b)
• Wing Profile
Table 6.2 – Inputs and Outputs for Aerodynamics domain.
6.2.2. Propulsion
The propulsion domain takes care of the propulsion system and everything that is related. Here
the engine between the options available is chosen, and the propellers are also tested, to reach
the best thrust result to the existent engine.
After choosing one of the engines, the subsystem specialists should join the data of available
propellers for that engine. After that, the engineer accesses an external tool “JavaProp” [16],
which calculates the thrust from the data of the engine and propeller (Figure 6.7).
Figure 6.7 – Propeller design button.
After clicking the button the function will open a window warning the engineer of the next steps
(Figure 6.8).
Figure 6.8 – Open Java Prop menu.
46
This tool is also free, available at the internet, like the one presented at the aerodynamics
subsystem. Both came from the same website. Again, this was the chosen tool because of its
efficiency, cost and ease of use, but other alternative tools could be used.
To reach a useful value for thrust, the tool needs the values of several parameters of the engine
and propeller. From the engine it is essential to know the rotational velocity in revolutions per
minute and the power in watt. From the propeller is essential to know the propeller diameter and
the spinner diameter. As an example, if we have a propeller “15x4” 15 representing the
propeller diameter and 4 the propeller pitch. Pitch is a theoretical measure that has the meaning
of distance that the propeller would move forward with 100% efficiency in an ideal way.
The input and output to other subsystems from this subsystem workbook is presented in Table
6.3.
Inputs Outputs
• Engine Model
• Engine Weight (23)
• Thrust (T )
• Engine Model
Table 6.3 – Inputs and Outputs for Propulsion Domain.
6.2.3. Avionics
In this domain all the issues and problems referring to avionics system will be evaluate and
solve.
Depending on the project design it will need more or less instruments, i. e. if it is a simple plane
or an aircraft with automated control. In the Aircargo Challenge case it will be a simple aircraft.
Therefore, it will be controlled by a pilot at the ground with a radio control system.
The radio control system needs a receptor with the frequency crystal, placed at the aircraft, and
an emitter, essentially the radio control. To receive a signal it is necessary that the receptor has
power, so it will need a battery to ensure that there is enough power the reception.
If the communication system is working it is important to set up the communication to the aircraft
control surfaces. The communication is done between the receptor and the server. This last one
could be a micro-server also, if the weight and size are essential. Then, the movement induced
by the user is created in the server, which transfers it to the aircraft control surface.
If perhaps, the mission is changed to an automated flight control or to a surveillance mission or
other, this is the domain responsible to take care of those issues, which include all the
electronic devices working functions, power and communications.
The output to other subsystems from this subsystem workbook is presented in Table 6.4.
47
Outputs
• Receptor Weight
• Servo Weight
• Micro-Servo Weight
• Number of Servos
• Number of Micro-Servos
• Battery Weight
Table 6.4 – Outputs for Avionics Domain.
6.2.4. Weight and Structure
In this domain all the values due to the weight and structure of the airplane are determined.
Since it was strictly necessary to aggregate domains due to the low number of computers in the
laboratory, one of the aggregations performed was the weight and the structure domain. The
reason is that they are very dependent on each other and it is a natural aggregation. The weight
depends on the kind of structure selected, and the structure is created depending of the weight
and existent instruments in the airplane.
The weight considers all the instruments needed inside the airplane and also the weight of the
structure, and finally reaching a final empty airplane weight, without payload.
This is an extremely important issue, estimate the empty airplane weight. This will lead the
project design to another phase, were the problem is to lift off the maximum amount of weight,
extra to the empty airplane known weight.
After that, the engineers will be concerned with the structure of the airplane. There are several
issues to solve when developing such airplane. Once the instruments are all chose, it is
essential to define an inside structure to fixed and fit them, considering the best material to do
the structure construction.
Inputs Outputs
• Receptor Weight
• Servo Weight
• Micro-Servo Weight
• Number of Servos
• Number of Micro-Servos
• Engine Weight (23)
• Battery Weight
• Total Weight of Empty Airplane
Table 6.5 – Inputs and Outputs for weight and structure domain.
48
The choice of the material should take into account several aspects: weight, resistance, shaping
easiness and price.
The output and input for this subsystem workbook are presented in Table 6.5.
6.2.5. Air Conditions, Costs and Requirements
There are several aspects to be treated at this subsystem workstation. The first domains
concerns the requirements of the mission, the second the costs of the project and finally the air
conditions at the take off track. These three domains where place together because they are
evaluate at the beginning and at the end of each iteration, i. e. once an iteration step is started
the requirements are evaluated, to know what to reach, the costs, to know if the project is still
realizable, and the conditions at the take off track, because that influences almost all
calculations done. Finally when the iteration step is almost ending, both these domains are
evaluate again, to see if the requirements are still completed, if the expenses are still within the
budget and if conditions at the track were completed too.
The requirements for this project design were presented at the beginning of the chapter, of
which are highlighted:
- The track length of 60 meters;
- The engine selection among the allowed engines list;
- The use of a non-metallic propeller, and;
- The limited aircraft lifting surface area of S=0,70 m2.
The costs will be responsible for the expenses control, as well as to control the available
budget. Since the air cargo project does not represent a complex project at costs level, it was
not assume any tool to do it, and can be easily done within the existent excel worksheet.
The air conditions domain intends to control the aspects related to the external environment
conditions at the track. Several issues influence the flight, especially the airfield altitude. The
altitude will influence the air density and consequently the flight performance.
To account the air conditions a simple tool to calculate the density as function of the altitude
was developed [27]:
7 1,225 J1 W R,RR�� {=��,N� L�,=���� , � � 11000 � (6.24)
7 0,36392 �tR,RRRN�����o{tNNRRRp , � � 11000 � (6.25)
6.2.6. Assembly and Presentation
This workbook does the final assembly of all data, allowing verification of the aircraft ability to
take off or not. This, of course, depends of all the other workbooks data, as well as intends to
49
send a feedback to all the workbooks questioning the right function of the aircraft system. It will
also be responsible for the presentation of the final results of each iteration.
The calculation, using the data from the other subsystems, will be done through the calculation
model presented at the chapter 6.1.1. First, the data received as an input to this subsystem
from the others is organized through domains in the calculation worksheet. Then, there are
calculated the values of bN (6.11) and b= (6.12), as well as the values of the stall speed (6.2)
and the take off speed needed for the existent track (6.3).
Therefore, is now possible to know the values of the variables the project design intends to
achieve, the take off speed, the thrust required or the track length needed. As explained before,
the take off speed achieved at this point assumes that the aircraft uses all the track length to the
take off, using a known value for the thrust. On the other hand, the track length needed value is
achieved to understand how much more the aircraft need to roll on the runway to take off, using
the known thrust and take off speed need values. Finally, the thrust required is calculated
assuming that the aircraft will reach the end of the track with the take off speed needed.
All the values explained and calculated before assume a value for the payload weight added by
the engineer at the calculation worksheet. The Figure 6.9 shows the calculation presentation
model.
Figure 6.9 – Calculation presentation model.
In the Figure 6.9 could be seen that near several calculations steps are buttons with an
interrogation mark, which, when clicked, open a small window showing the calculation formula
for that calculation step.
Each time the values change, it will be automatically shown if it is possible to take off with the
existent data. It will be shown in one cell at the calculation worksheet “Take Off OK”, for a
possible take off and “No Take Off” if the existent values don’t allow the take off (Figure 6.10).
50
Figure 6.10 – Presentations of the calculation results, if there is take off or not.
After calculating all the results, it is important to add them to a list of results, allowing later to
know all the results evolution. To accomplish that task a function was created (Figure 6.11) that
copies the most important variables values to a list existent at the “Layout_Results” worksheet
at the actual subsystem. The variables values copy are:
- Total Mass (W);
- Stall Speed ()*+,--);
- Take Off Speed Needed ()%&.//0);
- Take Off Speed ()%&);
- Landing Strip Length (#�);
- Thrust (T);
- Maximum Lift Coefficient (�AáB), and;
- Wing Reference Area (S).
Figure 6.11 – List values function button.
However, at the table list besides the variables values, the time and data of the listing is added
as well as the school year when the project design was done.
Figure 6.12 – Chart Creator Button.
Once the variables values are all listed it would be worth to analyze them through charts.
Therefore, a function was created (Figure 6.12) that allows the engineer to select the variables
he want to analyze.
The function starts opening a menu where the engineer could select the variables to analyze
(Figure 6.13). Then, after pressing the button “Draw Graph” the function will create a graphic
with the chose variables and will name give a title in function of them.
51
Figure 6.13 – Graphic creator menu.
To avoid a big mess with many existent graphics at the worksheet, once a new graphic is
created the function erases the existent ones. However, to avoid the lost of important
information for the design project, the function saves each graphic created in a folder named
“Charts” with the name including the date and time which it was created. These graphics are
also used to the knowledge management, keeping a record of the design changes during the
project, for future reference in other similar projects.
In this domain a graphic is also created which allows the design engineers to overview the
whole evolution of the project, and to analyze which variable value is not inside the parameters
allowed interval. One example of this graphics is shown in Figure 6.14.
Figure 6.14 – Example of one project design evolution results chart.
52
Inputs
• Maximum Lift Coefficient (�AáB)
• Reference Area (S)
• Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (')
• Lift induced drag coefficient (k)
• Ground Lift Coefficient (��)
• Thrust (T )
• Chord (c)
• Wing Span (b)
• Wing Profile
• Engine Model
Table 6.6 – Inputs for assembly and presentation domain.
The input for this subsystem workbook are presented at Table 6.6.
6.3. Procedure
Since all subsystems workbooks are explained in the previous chapters, is now time to explain
the procedure.
The procedure starts by analyzing the requirements, defining the external environment
conditions at the airfield, and the initial domains. These domains are the aerodynamics, avionics
and propulsion. Once a wing profile is chosen, the engine and all the instruments related to the
function of the aircraft, the structure and weight can be analyze. After that, the engineers may
verify the existence or not of a take off within the runway length. That will be achieved by using
the data defined as outputs from the subsystems.
The analysis proceeds, verifying the variable results and, if not in a correct function, re-start,
change values and solutions, and do the whole procedure again.
6.4. Validation
The initial tests with the concurrent engineering tool for the Aircargo Challenge were developed
using the “Icaro” configuration model [25]. That configuration model was used in 2005, where
combustion engines were still allowed.
After several interviews with team members of the Aircargo Challenge it was possible to gather
the most important data to start testing the system. This data is presented on Table 6.7.
53
������ (Kg) 1,801
T (N) 36
���á� 1,8
S (m2) 1
��� 0,07
��� 0,2
� 0,04
h (m) 0
b (m) 1,82
Table 6.7 – Variables values for Icaro aircraft.
After inserting the values the maximum payload weight was 13 Kg, in a first approximation, with
a take-off speed of 13,77 m/s using approximately 56,5 m of the runway. These values will be
shown next, comparing them to another aircraft.
The current Aircargo Challenge Competition only allows electric engines and restricts the lifting
surface area to 0,70 m2. One of the competitors is a team of IST Aerospace Engineering
students, with whom it was tried to achieve results, related to their aircraft.
Tests realized with this team were developed in mini-sessions, which depended of the
availability of the team members. In these mini-sessions the project design was discussed
focusing the variables values needed for the take off calculation.
������ (Kg) 1,6
��� 0,07
Table 6.8 – Assumed values for a first iteration in the project design of the aircraft of IST 2009 Team in the Aircargo Challenge.
In a first test several values were assumed to reach an approximation of the design. It was
assumed the empty aircraft weight and the drag coefficient. The assumed values are presented
in the Table 6.8.
Table 6.9 – Variables values already k
Once defined all the variables
the wing span. The first test was done assuming a wing span of
0,55 m2 and with a payload with the maximum weight possible.
saved to after compare with a second test results were the wing span was
the reference area and the weight of the first iteration. The wing with minor
a bigger cord value, which will result i
the end of the runway, or assuming the need of
is possible to notice that the increase of the wing span value
at the end of the track (VTO), which means that to achieve a take off with the
weight it would be necessary a bigger runway (Landing Strip Length) or a bigg
that is impossible because the runway length is defined by the competitions regulations as well
as the engine, the solution is reducing the payload weight, which is the opposite of the main
objective of the competition, which means that th
Figure 6.15 – Results of the
The initial tests also helped defining approximated values for the take
weight. The take-off speed will assume values between 12 m/s and 14 m/s, which was within
the expected values by the team, and the take
Kg.
54
T (N) 25
CCCCLLLLmáxmáxmáxmáx 2,5
S (m2) 0,55
CCCCLLLLGGGG 0,73
µ 0,04
h (m) 0
b (m) 1,6 or 2,2
Variables values already known to the 2009 aircraft.
variables several iterations were done, to reach a consensus
was done assuming a wing span of 2,2 m, with a reference area of
and with a payload with the maximum weight possible. The results achieved were
saved to after compare with a second test results were the wing span was 1,6
ference area and the weight of the first iteration. The wing with minor wing span will have
a bigger cord value, which will result in a bigger drag value and consequently a smaller speed at
the end of the runway, or assuming the need of take off, less payload weight. In the
to notice that the increase of the wing span value slightly reduces the speed reached
), which means that to achieve a take off with the
weight it would be necessary a bigger runway (Landing Strip Length) or a bigg
that is impossible because the runway length is defined by the competitions regulations as well
as the engine, the solution is reducing the payload weight, which is the opposite of the main
, which means that the best wing span value will be
Results of the first two iterations where the value of the wing span
tests also helped defining approximated values for the take-off speed and the payload
off speed will assume values between 12 m/s and 14 m/s, which was within
the expected values by the team, and the take-off weight for the payload was ap
to the 2009 aircraft.
, to reach a consensus referring to
m, with a reference area of
The results achieved were
1,6 m maintaining
wing span will have
n a bigger drag value and consequently a smaller speed at
take off, less payload weight. In the Figure 6.15
reduces the speed reached
), which means that to achieve a take off with the same payload
weight it would be necessary a bigger runway (Landing Strip Length) or a bigger thrust. Since
that is impossible because the runway length is defined by the competitions regulations as well
as the engine, the solution is reducing the payload weight, which is the opposite of the main
e best wing span value will be at most, 2,2m.
first two iterations where the value of the wing span varies.
off speed and the payload
off speed will assume values between 12 m/s and 14 m/s, which was within
off weight for the payload was approximately 9
55
After these tests the team notices that the weight was within the expectations, but was probably
high because the thrust of the engine was assumed constant and equal to the maximum value
of 25 N. This was not correct because it decreases with a rate of 0,7 N/(m/s) with the aircraft
rolling speed, value calculated by the team.
In the following iteration it was considered an estimation for the thrust value taking into account
the decreasing rate. Comparing the values calculated in the first iteration with the new iteration,
taking into account the decreasing of thrust value, it is apparent that the total mass of the
aircraft has been reduced in order to achieve a take-off speed in the available runway (Figure
6.16).
Figure 6.16 – Comparing iterations 1 and 3, where the thrust value varies.
A last iteration was preformed trying to reach an optimization of the drag coefficient value. The
initial value defined for this variable was ���= 0,07 which wasn’t too far of the real value,
achieved by the aerodynamics domain engineers ��� = 0,06. Changes due to this value are
presented in the Figure 6.17.
Figure 6.17 – Comparing iterations 3 and 4, where the defined CDo changed.
The changes in the thrust need and take off speed are not significant, but there is a slightly
reduction in the length of the runway which means that probably could be considered an
increase of the payload weight.
56
The Figure 6.18 compares the main variables data for the presented aircrafts, the Icaro and the
2009 aircraft. It is apparent that the bigger value of thrust for a combustion engine allows a
bigger payload weight. The take off speed is also bigger, and there are some differences
between the aerodynamics profiles.
Figure 6.18 – Comparing Icaro and 2009 aircraft.
6.5. Discussion
The use of the concurrent design facility at IST by student teams wasn’t straight forward.
Several difficulties were found in the adaptation to the application. However it is
understandable, because adopting a new way of doing things often needs a change in the
mentality of the people involved, even if it seems better, and only with their adherence to the
method, results can improve. The verified difficulties might also refer to a missing initial study in
the design facility, since the organized mini-sessions happen when the project had already
started. Considering that future studies should use the tool from the beginning, the difficulties
should be easily overcome.
The calculation model was reached after testing several different models, and after
conferencing with the teams. The results of the present calculation model reveal accuracy and
meet the expectations, existent among the teams. The data achieved by this model is more
complete, revealing important information that teams had not reached by their calculations,
contributing to their learning process and to a better result.
The presentation of all data and results was implemented trying to reach a compromise
between simplicity and completeness. The reached solution facilitates the project overview at
any time, and the understanding of the cause effect of each single variable to the system. This
shows the importance and usefulness of the concurrent engineering method during the project
design, in particular, in a student environment.
Other issue concerning the project design was the definition of the subsystem domains and,
their distribution by the available workstations. The definition and distribution was reached
easily, supported by the concurrent engineering method, showing, again, the utility of the
method, but now in an early project development phase.
The tests revealed that the definition and distribution works properly, ensuring an adequate
evolution of the project design. However, after the mini-sessions organized within the Aircargo
57
team, the possibility of a new domain of aircraft stability, which would give as outputs the
longitudinal and lateral dynamic matrices, could help achieving better results.
The domains also needed specific tools for their own design, which were chosen regarding their
efficiency and ease of use. Here, the tests revealed that the chosen tools were not the best
ones, although still adequate. The team suggested the use of a new tool in the aerodynamics
domain called “XFLR 5”, since this program returns the aerodynamics parameters values
referring to the whole plane and not only of the wing analysis.
The use of the Aircargo application by the current Aircargo team revealed to be useful since it
made possible to understand, what was the approximated payload weight that the aircraft could
take-off. Using this information, it was then possible to adapt and test new solutions and
visualize the response of the system, reaching a better solution at the end.
58
7. Conclusion
Implementing the Student Concurrent Design Environment tool, and a new application to be
used as test case and by students, in the aerospace laboratory at Instituto Superior Técnico,
was the main objective of this thesis. This implementation includes the functionality of the
software and hardware systems, and the adaptation of the laboratory room into a reasonable
concurrent engineering design facility. The tool was implemented with success and early results
indicate that the concurrent engineering design facility can be used with success by University
students, and be a useful instrument in projects such as the Aircargo Challenge. Some
difficulties especially the ones regarding the Microsoft Excel and the restrictions of space at the
laboratory, were overcome with success.
The initial adaptation of students testing the system to the new method was not easy because it
always takes some time to reach a good link between the users and the tool. This is to be
expected since it was a new way of thinking, and it has been described in literature about
concurrent engineering as one of the major difficulties. The solution is to develop a concurrent
engineering mentality within the students from the beginning, as a potential and easiest method
to all kind of projects design. This environment can strongly contribute to the academic
formation of the students.
The creation of a small interactive and automated knowledge management tool, allowing users
to record the comments and changes during the project design, turned into a valid and
functional option, approved by the users, and hopefully by the future users, since it will enable
the existence of results in the future for comparison. At this time it is not possible to measure
the impact of this tool since it requires a timeframe incompatible with this thesis.
The visualization, recording and evaluation functions developed at the application project
revealed to be of high importance, and with an extreme utility for the project design, since it
allows users and other to constantly know the evolution of the project. That was confirmed by
an extended use of these functions by the students during testing in the Aircargo aircraft design.
This presentation of the results also works as a knowledge base for future reference in the
institution, since it allows access and evaluation at any time.
After the tests developed with the Aircargo team several questions were posed in order to
understand the evaluation of the application developed, by the team members. There were
several suggestions, included in the discussion of the tests. In general, the system was
considered very useful and as a powerful project design tool by the teams. The possibilities
enabled by the concurrent engineering were also praised, showing the validity of the method in
university projects.
The limited number of Aircargo Challenge competition teams to test in real conditions the
application was a limitation, since there was always a limitation on the time available with the
team members. The solution found to this limitation was to use results from old Aircargo
59
Challenge teams, but these didn’t allow a design through concurrent engineering method since
the essential human element was missing, and the concurrent process absent.
Other limitation was the availability of licenses to specific software at IST. Other more
sophisticated programs should allow a more competitive project design. However, the flexibility
of the tool demonstrates that in the case of absence of the optimal tools, alternatives can be
used to achieve results. It is not clear what is the impact of using the most adequate tools but
the possibility of using free tools should be praise, especially in projects of limited size, as
software licenses can be very expensive and resources are usually limited. This could perfectly
apply to the case of small and medium size companies, with similar situations, and can
constitute an advantage to be taken into account. Trading cost by power is not always the best
choice in all situations.
Overcoming all kind of difficulties it is possible to affirm that at IST there is a concurrent
engineering design facility functioning correctly, and an aircraft design through the concurrent
engineering method is also available to students’ projects in the future.
60
8. Future
The conclusions and limitations of the present study suggested many possibilities of future
developments of this work. The following list does not intend to be exhaustive and features only
the most relevant. It is also important to emphasize that a constant update of all tools involved
in the process, is an essential requirement.
The most important issues to be addressed in the future are:
• Consideration of an alternative solution for the main tool (Microsoft Excel).
• Consideration of new visual developments alike the included in the current thesis, it
would worth to think and idealize new visual solutions to the presentation of the design
process.
• The evolution of the Aircargo Challenge features. This involves the design of an
improved calculation model for the Aircargo Challenge aircraft. This new calculation
model, could take advantage of new and improved tools added to the actual design
system. The tools should be better and efficient for all the domains issues. However, a
future work should focus on the aerodynamic studies, as referred in the previous
chapter, because this seems to be the most exhausting part of the aircraft design
process in this case. Building and developing a reliable design process for the
aerodynamics systems should clearly facilitate the whole project design. Also the
creation of the new domain (stability), suggested by the actual Aircargo team, could
increase the validation of the model.
• Besides the evolution of the Aircargo Challenge design project, the creation of a design
project environment applied to other kinds of aircrafts could also be considered. It would
have several applications during the aerospace engineering course disciplines.
61
9. Bibliography
[1] Bandecchi, M., Milton, B., Gardini, B., The ESA/ESTEC Concurrent Design Facility, in
Proceedings of EuSEC 2000, 2000.
[2] Karpati, G., Martin, J., Steiner, M., Reinhardt, K., The Integrated Mission Design Center
(IMDC) At NASA Goddard Space Flight Center, presented on Aerospace Conference,
2003.
[3] Mclnnes, A., Integrated Concurrent Design – Making the Conceptual Design Process
Faster, Better, and Cheaper, The Aerospace Corporation, 2003.
[4] Thomas, D., Concurrent Engineering at the Aerospace Corporation, shared at CPDA’s
2006 Design/Simulation Integration Workshop, Atlanta, 2006.
[5] T.J.B., Sheets for the Aerospace Project I Discipline, Instituto Superior Técnico, 2007.
[6] Bandecchi, M., The ESA Concurrent Design Facility (CDF): concurrent engineering
applied to space mission assessments, presented on 2nd
Nordic System Engineering
Boat Seminar, Finland, 2001.
[7] Bandecchi, M., Gunner, J., Matthyssen, A., Distribution of the ESA CDF Concurrent
Design tools and methodologies, presented on 2nd
CE for Space Application
Workshop, Netherlands, 2006.
[8] Vasile, M., Radice, G., A Multi-Agent System for Distributed Concurrent Engineering,
presented on 2nd CE for Space Application Workshop, Netherlands, 2006.
[9] Bandecchi, M., Melton, B., Concurrent Engineering Applied to Space Mission
Assessment and Design, ESA bulletin 99, September 1999.
[10] Bruggen, F., The ESA Concurrent Design Facility (CDF): concurrent engineering
applied to space mission assessments, CDF info pack, provided on the CDF Web site
http://www.esa.int/cdf , 2006.
[11] Valen-Sendstad, M., Veritas, D., Bengston, K., Open Concurrent Design Facility Server
(OCDFS) for ESA, presented on Concurrent Engineering for Space Applications
Workshop, Netherlands, 2004.
[12] Bandecci, M., Maththyssen, A., ESA Open Concurrent Design Sever, presented on
2nd
CE for Space Application Workshop, Netherlands, 2006.
[13] Beco, S., Parrini, A., Paccagnini, C., Architecture of a Grid-based Virtual Collaborative
Facility for Space Projects, presented on 2nd
CE for Space Application Workshop,
Netherlands, 2006.
[14] Bandecchi, M., Gunner, J., ESA iCDF, presented on 2nd
CE for Space Application
Workshop, Netherlands, 2006.
62
[15] JavaFoil tool. Available online at: http://www.mh-aerotools.de/airfoils/javafoil.htm.
[16] JavaProp tool. Available online at: http://www.mh-aerotools.de/airfoils/javaprop.htm.
[17] Aircargo Challenge Regulations, Portuguese Association of Aeronautics and Space,
Lisboa, 2007.
[18] Aircargo Challenge Regulations, Association of Aeronautical Engineering of Beira
Interior University, Covilhã, 2008.
[19] Bandecchi, M., Garutti, A., Haines, J., Spacecraft Electrical Power Subsystem Design
Utilising the ESA-ESTEC Concurrent Design Facility, presented on CDF - Power
Electronics Specialists Conference, 2001.
[20] Bandecchi, M., From the CDF Concept to Distributed Concurrent Engineering,
presented on 2nd
ESA Space System Design, Verification and ATI Workshop,
Netherlands, 2003.
[21] Bandecchi, M., Concurrent Engineering at ESA: From Concurrent Design Facility (CDF)
to Distributed Virtual Facility, presented on The 14th ISPE International Conference on
Concurrent Engineering, Brazil, 2007.
[22] Weck, O., Integrated Concurrent Engineering, ESD.36 System and Project
Management, Massachusetts Institute of Technology (MIT), U.S.A., 2003.
[23] Costa, S., Controlo e Simulação de um Quadrirotor Convencional, Master thesis,
Instituto Superior Técnico, Lisboa, 2007.
[24] Costa, A., Ribeiro, D., Melo, F., Gaspar, R., Lopes, S., Kerberos - Sistema Aéreo de
Vigilância Florestal e Detecção de Fogos, Universidade da Beira Interior (UBI),
Covilhã, 2007.
[25] Pinto, J., Cardoso, C., Loureiro, J., Fouto, A., Moreira, H., Penedo, R., Cruz, L., Santos,
H., Relatório de Projecto Aircargo Challenge – Icaro, Instituto Superior Técnico, Lisboa,
2005.
[26] Cardoso, C., Loureiro, J., Fouto, Relatório de Projecto Icaro - Brasil, Instituto Superior
Técnico, Lisboa, 2005.
[27] Roskam, J., Lan, C., Airplane Aerodynamic and Performance, DARCorporation, U.S.A.,
1997.
[28] Raymer, P., Aircraft Design: A Conceptual Approach, American Institute of Aeronautics
and Astronautics, Inc., U.S.A., 1992.
[29] Corke, T., Design of Aircraft, Prentice Hall, U.S.A., 2002.
[30] Trottemant, E., Pont, G., Ilsen, S., Student Concurrent Design Environment User
Manual (Demo), Netherlands, 2005.
63
[31] Lomax, P., VB & VBA in a Nutshell: The Language, O’Reilly & Associates, Inc, U.S.A.,
1998.
[32] Green, J., Bullen, S., Bovey, R., Alexander, M., Excel® 2007 VBA Programmer’s
Reference, Wiley Publishing, Inc., U.S.A., 2007.
[33] Mansfield, R., Mastering VBA for Microsoft® Office 2007, Wiley Publishing, Inc., U.S.A.,
2007.
[34] Loureiro, H., Excel 2007 Macros e VBA – Curso Completo, FCA – Editora de
Informática , Lda, Lisboa, 2007.
[35] Smith, P., Dawdy, A., Trafton, T., Novak, R., Presley, S., Concurrent Design at
Aerospace, at www.aero.org/publications/, July 2008.
[36] EADS Space Transportation Inaugurates State-of-art Design Office, at
www.astrium.eads.net/press-center/press-releases/2005, July 2008.
[37] www.esa.int/CDF, July 2008.
64
Annexes
65
Annex A - Student Concurrent Design Environment Portuguese
User Manual
A.1. Introdução
Este manual visa auxiliar a utilização do software de engenharia concorrente, existente no
laboratório de aeroespacial no Instituto Superior Técnico. Esse software, denominado “Student
Concurrent Design Environment”, foi disponibilizado pela ESA (European Space Agency).
Será importante salvaguardar que existem termos, usados em inglês, que não têm uma
tradução exacta em português, os quais não serão assim traduzidos ao longo deste manual,
evitando assim conflitos linguísticos de interpretação. A título de exemplo refere-se o
“workbook”, identificativo do ficheiro/livro Excel, ou até mesmo “worksheet” identificativo de um
“tab”/folha existente em cada ficheiro.
Este documento inicia-se com uma breve explicação do conceito no qual reside o software,
seguida de uma explicação da sua correcta instalação. Posteriormente, será dada uma noção
ao utilizador das possibilidades inerentes a um engenheiro de subsistemas bem como a um
engenheiro de sistema.
A.1.1. O conceito do Modelo
O modelo é composto por dois tipos diferentes de workbooks do Excel, nomeadamente o
workbook do servidor denominado “Data Exchange” e os diferentes workbooks
correspondentes aos subsistemas (S/S). No workbook do servidor constam todos os
parâmetros e ferramentas que todos os subsistemas necessitam, enquanto os workbooks de
cada subsistema contem a informação e ferramentas necessárias para o seu correcto
desenvolvimento. Para existir um funcionamento correcto, é necessário que os workbooks dos
subsistemas e do servidor se encontrem na mesma pasta. Existe ainda um workbook que
regista todos os pedidos efectuados por todos os subsistemas, denominado “Parameters”.
66
Figura A.1 – Modelo geral do conceito SCDE.
Cada workbook de um subsistema é composto por diferentes worksheets, cada uma delas com
a sua função específica. Assim, podem caracterizar-se por três tipos diferentes,
nomeadamente worksheets de “input”, “output” e “calculation”. A função da primeira é a de
obter os parâmetros do servidor, “Data Exchange”, para o workbook do subsistema. O “output”
servirá para juntar todos os parâmetros pedidos pelos outros subsistemas e enviá-los para os
mesmos. Por fim, o tipo de worksheet “calculation” é usado para efectuar cálculos necessários
ao desenvolvimento do subsistema, para guardar informação obtida do hardware, para receber
parâmetros de ferramentas exteriores, entre outras funções.
Figura A.2– Tipos de worksheet de um subsistema no SCDE.
67
A.2. Instalação do SCDE
A.2.1. Criação da directoria
Existem três ficheiros incluídos no SCDE de importância vital ao funcionamento do mesmo:
Modelo
- Subsystem.xls Workbook do subsistema;
- Data_exchange.xls Workbook do data exchange;
- Parameters.xls Workbook dos parâmetros.
- Comments_Changes_Tracking.xls Workbook dos comentários e alterações
Base de dados dos componentes
- Comp_database.mdb Base de dados dos componentes.
É importante que todos os membros das equipas tenham acesso ao directório onde se
encontram estes ficheiros e que todos os subsistemas sejam guardados nesse mesmo
directório. Quer isto dizer que, todos os computadores devem estar ligados em rede com um
computador central que guardará todos os workbooks do projecto.
Por defeito estes ficheiros estão localizados em “C:\CDF”.
Agregado a estes ficheiros vêem também os ficheiros correspondentes ao desenvolvimento do
projecto air cargo que será explicado mais tarde.
Criação de um workbook de um subsistema
Para um efectivo funcionamento do modelo é necessário o trabalho de vários domínios em
cooperação. Dado que o modelo apenas contempla um subsistema inicial, dever-se-á criar
novos subsistemas, criando assim novos domínios de trabalho no projecto. Para tal, bastará
copiar o ficheiro “Subsystem.xls” e dar-lhe outro nome consoante o domínio a que se irá referir.
No entanto, é necessário manter todos os subsistemas, bem como do workbook “Data
Exchange”, na mesma directoria conforme referido no capítulo anterior.
O workbook “Data Exchange” é usado para copiar as worksheets “Output” de todos os
subsistemas durante a actualização do modelo. No entanto, para que todos os subsistemas
sejam identificados e actualizados é necessário que se adicione à coluna A da worksheet
“Administration” do workbook “Data Exchange” o nome do ficheiro de todos os subsistemas,
e.g. Subsystem.xls.
68
A.3. Trabalhar com o SCDE, sendo um engenheiro de
subsistemas
A.3.1. Worksheet “administration”
A worksheet “Administration” presente em todos os workbooks de cada subsistema serve para
registar todas as pequenas ou grandes alterações no domínio do subsistema. Esta worksheet,
que é regularmente actualizada, oferece uma visão da história do subsistema, mas oferece
também informação útil quando outro membro da equipa utilizar o workbook em causa.
A.3.2. Transferir dados de e para o “Data Exchange”
Todo o método de engenharia concorrente é baseado numa rápida troca de parâmetros de
projecto, sendo que esta transacção de dados é feita através do workbook “data exchange”.
Este workbook não é nada mais do que uma compilação de todas as worksheets de “output”
das diferentes áreas de projecto.
Assim, todos os parâmetros requisitados por outros domínios estão guardados na worksheet
“output” de cada domínio, e existe também, para cada domínio, um workbook de “inputs” onde
são listados e guardados todos os parâmetros provenientes dos outros domínios que poderão
ser usados nas suas worksheets de cálculos. Sendo que a inserção correcta dos parâmetros é
essencial para o funcionamento do sistema, é dada uma explicação mais aprofundada dos
campos que compõe as worksheets de “output” e de “input”.
Output
Parameter Na coluna A, é dada uma descrição geral do parâmetro a introduzir.
Cell name A definição do nome do parâmetro é feita na coluna B.
Internally linked
Esta célula será associada á célula com o resultado dos cálculos/design do parâmetro na worksheet de cálculos do domínio em causa. Isto pode ser feito clicando na célula da coluna C, inserir um “=” e posteriormente clicar na célula da worksheet de cálculos que se pretende associar a este parâmetro.
Manual value
Esta célula é usada quando o parâmetro requisitado ainda não está disponível. Assim, é inserido na coluna D, um valor manualmente para evitar a interrupção do processo de iteração.
Units Na coluna E, são inseridas as unidades do parâmetro, sempre em unidades SI para evitar conversões de unidades entre domínios diferentes.
Switch
Ao clicar nesta célula será apresentado um menu com três opções:
“Manual” “Linked” “Not shared”
O valor da coluna D (Manual value), é copiado para a coluna G.
O valor da coluna C (Internally linked), é copiado para a coluna G.
Não é copiado nenhum valor para a coluna G.
69
Shared value
O valor na coluna G é o valor actual do parâmetro e que será copiado para o “data exchange” e daí partilhado com todos os outros subsistemas. O valor apresentado é definido pelo “switch” na coluna F.
Remarks Notas gerais sobre o parâmetro podem ser inseridas na coluna H.
Tabela A.1– Descrição detalhada dos campos existentes para preenchimento numa worksheet de “output”.
Input
Parameter Na coluna A, é dada uma descrição geral do parâmetro, podendo ser uma descrição particular definida no domínio em causa ou uma cópia da descrição apresentada no “data exchange”.
Linked value
Esta célula será associada á célula no “data exchange” com o valor do parâmetro em causa. Isto pode ser feito clicando na célula da coluna B, inserir um “=” e posteriormente clicar na célula do “data exchange” que se pretende associar a este parâmetro ou inserir o nome do parâmetro do workbook “data exchange”.
Manual value
Esta célula é usada quando o parâmetro requisitado ainda não está disponível. Assim, é inserido na coluna C, um valor manualmente para evitar a interrupção do processo de iteração.
External Esta célula também pode ser associada a um parâmetro gerado com ferramentas externas. Normalmente é convertido o output das ferramentas numa worksheet de cálculos e depois associar o parâmetro à célula da coluna D.
Switch
Ao clicar nesta célula será apresentado um menu com três opções:
“Manual” “Linked” “External”
O valor da coluna C (Manual value), é copiado para a coluna G.
O valor da coluna B (Internally linked), é copiado para a coluna G.
O valor da coluna D (External), é copiado para a coluna G.
Cell name Definição do nome do parâmetro no workbook “data exchange”.
Used value
O valor na coluna G é o valor actual do parâmetro e que poderá ser usado pelo domínio em causa as suas worksheets de cálculo. O valor apresentado é definido pelo “switch” na coluna E.
Units Na coluna H, são apresentadas as unidades do parâmetro, sempre em unidades SI para evitar conversões de unidades entre domínios diferentes.
Source O domínio de onde vem o parâmetro é apresentado na coluna I.
Status Se aplicável, indicar aqui se os dados estão disponíveis, precisam de ser revistos, calculados, etc.
Remarks Notas gerais sobre o parâmetro podem ser inseridas na coluna K.
Tabela A.2– Descrição detalhada dos campos existentes para preenchimento numa worksheet de “input”.
70
A forma de inserir parâmetros através do “input” é bastante linear, mas para que funcione é
necessário que o parâmetro tenha já sido disponibilizado no “data exchange” através da
worksheet de “output” do outro domínio. Assim, o primeiro passo é clicar no botão denominado
“Insert Parameters”, existente na worksheet “input”. Posteriormente aparecerá a janela
“Subsystem Selection”, Figura A.3, para que seja seleccionado o domínio do qual se pretende
o parâmetro.
Figura A.3– Janela “Subsystem Selection”.
Seguidamente surgirá uma nova janela “Select Parameters from selected/chosen Subsystem”,
Figura A.4, e irá ser apresentada uma lista de todos os parâmetros disponibilizados pelo
subsistema escolhido. Seleccione um ou mais parâmetros, assinalando a caixa junto ao
mesmo, seleccionando de seguida a linha (não a célula) na worksheet “input” e clique “Insert
parameters”.
71
Figura A.4– Janela “Select Parameters from selected/chosen Subsystem”.
Para o desenvolvimento de um sistema efectivo de engenharia concorrente, é necessário o
correcto funcionamento da comunicação e partilha de parâmetros via worksheets de “Inputs” e
“Outputs”, evitando ligações a worksheets de cálculo fora do workbook de trabalho do domínio
em causa.
A.3.3. Pedidos de parâmetros
A troca e partilha eficientes e rápidas de parâmetros são a base do processo em engenharia
concorrente. Assim, o processo de pedidos é automático para possibilitar essa eficiência.
Assim para efectuar um pedido deverá:
1) Seleccionar a worksheet, do workbook do seu subsistema, denominada “Requested by
me”.
2) Clicar no botão “Post a request”.
3) Definir de que domínio/subsistema necessita do parâmetro.
4) Inserir uma pequena descrição do parâmetro pedido.
5) Inserir as unidades preferenciais.
6) Clicar no botão “Post the Request”.
72
Figura A.5– Janela “Post a Request”.
A.3.4. Inserir Comentário
Dado que o acompanhamento do trabalho, bem como a o registo de todas as alterações, são
de extrema importância, existe em cada worksheet, um botão para a inserção destes (Add
Comment to List). A janela para tal está presente na Figura A.6.
73
Figura A.6 – Janela “Insert Comment”.
Adicionado o tipo de comentário, o comentário em si e as palavras chave associadas ao
mesmo, este é adicionado a uma lista presente na worksheet “Administration” de cada
subsistema e, também, à lista geral de comentários e alterações existente no ficheiro
“Comments_Changes_Tracking”.
A.3.5. Eliminar Comentário
É possivel eliminar um comentário da lista existente na worksheet “Administration”, através do
menu presente na Figura A.7, que aparece pressionando o botão existente na worksheet
referida (Delete Comment).
Figura A.7 – Janela “Delete Comment”.
74
Bastará seleccionar a linha onde se encontra o comentário através do menu existente na
janela, e a lista será actualizada.
É de frizar, no entanto, que para evitar que ocorram lapsos na eliminação de comentários, esta
só é feita na lista existente em cada subsistema e não na lista geral existente no ficheiro
“Comments_Changes_Tracking”.
A.4. Trabalhar com o SCDE, sendo um engenheiro de sistema
Um engenheiro de sistema será, durante um estudo, a autoridade central responsável pelo
acompanhamento e actualização do “data_exchange”. Será também responsável pelos
orçamentos, custos, objectivos e requisitos, fases da missão e coordenação temporal do
desenvolvimento da mesma. É importante que todos estes pontos estejam bem descritos e
documentados no seu workbook de trabalho.
A.4.1. Administração do estudo
Sendo então o engenheiro de sistema responsável pelo “data_exchange” é crucial que este
seja devidamente preparado antes do começo de qualquer estudo. Assim, deverá começar por
definir a data, a versão do “data_exchange” e o nome da missão/projecto na worksheet
“Administration” do workbook “Data_exchange”. Posteriormente nessa mesma worksheet,
deverá listar todos os subsistemas pertencentes ao estudo na coluna A, tendo o cuidado de ao
inserir o nome do subsistema este seja correspondente ao nome do ficheiro, incluindo também
a extensão “*.xls”. Todos os subsistemas listados deverão estar presentes na mesma pasta do
ficheiro “Data_exchange”.
A cada iteração realizada, cujo processo será explicado de seguida, está associado um número
da versão do trabalho. Esse número é composto por 3 algarismos, por ex. 3.08. O primeiro
número refere-se ao fase de design do modelo em causa, isto é, poder-se-á ter um estudo de
um modelo divido em mais que uma fase, sendo que no exemplo a fase do projecto será a
terceira fase. Assim, distinguir-se-á facilmente a que fase corresponde a versão em causa. A
seguir ao ponto existem dois algarismos que não são mais que o número da iteração em causa
para a fase em estudo, como no exemplo dado o projecto da fase 3 encontra-se na oitava
iteração.
75
Figura A.8 – Janela “Update Data Exchange Version”.
Para efectuar a actualização do “data_exchange” é necessário ir à barra de menus do Excel ao
menu “Update -> Update data Exchange” e irá aparecer a janela apresentada na Figura A.8,
onde são intuitivas as opções disponibilizadas. O primeiro ponto refere-se ao método de
actualização, sendo mais recomendado o método automático mas, caso seja necessária
alguma correcção, pode usar-se o método manual. De seguida a janela apresenta a
especificação do nível de actualização. Caso a actualização seja referente à mesma fase, isto
é, avançar apenas uma iteração, deverá seleccionar-se o “New Version (Minor changes)”, valor
assinalado por defeito, mas caso se queira mudar de fase deve-se assinalar a outra opção
“New Issue (Major changes)”. Bastará de seguida clicar em “Update Now” para prosseguir com
a actualização e surgirá outra janela, representada na Figura A.9.
76
Figura A.9 – Janela “Update Data Exchange”.
Nesta janela deverão ser seleccionados todos os subsistemas que necessitam de ser
actualizados, assinalando para tal a caixa antes do nome do subsistema. Poderá no entanto
seleccionar-se todos os subsistemas clicando na opção “Select All”. De notar que todos os
subsistemas a actualizar devem estar fechados, continuando apenas com a actualização
quando após clicar em “Check Status” todos os subsistemas a actualizar aparecem como
fechados.
Nesta janela é possível também efectuar a actualização do “Parameter Exchange” sendo que
para tal bastará assinalar a caixa em “Update Parameter Exchange” e todas transferências de
parâmetros serão actualizados.
77
A.5. Aircargo Challenge
A.5.1. Modelo de Cálculo
Assumindo que as superficies aerodinâmicas foram já definidas pelos engenheiros do
subsistema de aerodinâmica, bem como o motor foi já escolhido pelos engenheiros do
subsistema de propulsão, é possível definir o modelo de cálculo.
Fundamentalmente a descolagem de uma aeronave consiste na transição de descanso a uma
velocidade suficiente para descolar da pista ()%&), efectuar a rotação e ultrapassar uma altitude
de referência definida por um obstáculo. Essa distância é denominada por #%&. No entanto,
neste projecto será considerada apenas a distância de rolamento na pista e a distância de
rotação (Figura A.10).
Figura A.10 – Distância de descolagem.
A distância de rolamento em pista é denominada por #� , sendo que é a parte em que o avião
vai de uma velocidade nula a uma velocidade de descolagem. Posteriormente surge a distância
de rotação (#$), onde a aeronave efectua a manobra de rotação, iniciando a subida a um
ângulo de ataque previamente definido.
A distância total será definida por:
#%& 7 #� 8 #$. (A.1)
A velocidade de descolagem é definida através da velocidade de perda ()*+,--)
)*+,-- 7 :;<
=> ?@AáB
CDE , (A.2)
resultando,
)%&.//0 7 1,2)*+,-- 7 1,2 :;<
=> ?@AáB
CDE . (A.3)
A distância de descolagem é calculada através da aceleração:
#� 7 I JK,L M) 7 N
= I OKEO,
KPQ.//0RKPQ.//0R (A.4)
em que a aceleração é determinada por,
78
� 7 S;PQ
∑ �� 7 S;PQ UV W � W ��X (A.5)
onde �� força de resistência ao rolamento, dada por
�� 7 'Y2%& W ��Z. (A.6)
A Figura A.11 mostra o esquema de forces a actuar na aeronave durante o rolamento na pista.
O coeficiente de fricção no rolamento ', varia com o tipo de pista, ' [ Y0,04; 0,08Z. �� é a
sustentação gerada durante o rolamento, baseada na melhor configuração da asa para criação
de sustentação, bem como do ângulo de ataque produzido quando o avião se encontra no dito
rolamento.
�� 7 �`��, (A.7)
onde q é a pressão dinâmica,
� 7 > KE= . (A.8)
Figura A.11 – Forças a actuar na aeronave durante o rolamento na pista.
Em relação à força de arrasto (A.9), esta é definida baseada no coeficiente de arrasto, ��, e no
coeficiente de arrasto induzido pela sustentação, ��.
� 7 �� 8 � ��=. (A.9)
Para determiner a distância de rolamento, usando (A.4), é necessário assumir primeiramente
que T/W é constante, caso contrário apenas seria possível calcular se o integral fosse resolvido
numericamente, fazendo variar em pequenos valores a velocidade, onde aí T/W é
definitivamente constante e igual ao impulso máximo a cada valor superior da velocidade.
Assim, a aceleração resulta:
� 7 bN 8 b=)=, (A.10)
onde
bN 7 c J %; W 'L (A.11)
79
e
b= 7 S >=Jd
e L f' �� W ��R W � ��g. (A.12)
assim
#� 7 I hKE�Di�EKE
KPQ.//0R 7 N= �E j� k�Di�E KPQ.//0
E�D l. (A.13)
Em relação à distância de rotação, esta é calculada assumindo que o ângulo de ataque
aumenta até que � 7 0,8�AáB . Por convenção, está definido que isto acontece três segundos
após o início da rotação. Assim:
#$ 7 3)%&. (A.14)
No entanto, dado que o resultado para esta distância é bastante elevado, foi definido um valor
para a distância de rotação de #$ = 2 m.
A equação (A.3), define a velocidade necessária para a descolagem. No entanto pode ser
bastante útil, conhecendo o comprimento total da pista, determinar a velocidade alcançada pela
aeronave, no fim da pista.
Assim, é assumido agora que o avião utilizará toda a pista existente para descolar,
maximizando o peso com o qual será capaz de descolar.
A partir de (A.13), é possível de determinar a velocidade de descolagem em função da
distância de descolagem, conhecendo também o valor do impulso gerado
)%& 7 n�D�E
o�=�E*� W 1p . (A.15)
Assim com é possível determiner a velocidade de descolagem, conhecendo o comprimento da
pista e o impulse disponível, é possível também determinar o impulso necessário para que, no
final da pista, a aeronave atinga a velocidade de descolagem.
Usando novamente (A.13), bem como (A.11), para determinar o valor do impulso, resulta
V 7 k)%&= b= NfqErEs�tNgS 8 'l 2. (A.16)
Para determinar o sistema propulsor, através do valor do impulso, requer alguns cálculos
adicionais, tais como o coeficiente de impulso, �%, bem como o coeficiente de potência, ��, que
são específicos de cada hélice.
�% 7 %>uE�v , (A.17) �� 7 �
>uw�x , (A.18)
onde n é a velocidade rotacional da hélice, D é o diâmetro da hélice e P a potência transmitida
pelo motor.
80
A equação da eficiência da hélice é dada por:
�� 7 %{|}*+ �~�q| &}+5}+<{,�+ �~�q| �u5}+ 7 %K
� , (A.19)
onde V, é a velocidade real do avião.
A equação do advanced ratio é dada por:
� 7 Ku�, (A.20)
Combinando as duas expressões anteriores resulta que
V 7 �u�
?P?� . (A.21)
A.5.2. Dominios
Para efectuar o projecto de design do air cargo foram criados os subsistemas presentes na
(Tabela A.3), onde aqui encontram-se já associados à respectiva estação de trabalho.
Estação de
Trabalho 1
Server
Requirements, Costs & Air Conditions
Assembly & Presentation
Estação de
Trabalho 2 Aerodynamics
Estação de
Trabalho 3 Avionics
Estação de
Trabalho 4 Propulsion
Estação de
Trabalho 5 Weight & Structure
Tabela A.3– Subsistemas criados, associados à respectiva estação de trabalho.
Existem nalguns domínios particularidades associadas aos mesmos que serão
explicadas seguidamente.
No dominio de aerodinâmica, existe um botão (Open Wing Design) destinado à
abertura do programa “JavaFoil”, onde se poderá criar e estudar todos os aspectos
relacionados com a asa da aeronave.
Usando os dados criados pelo programa é possível re-criar a asa no workbook do subsistema
actual. Para tal, bastará após clicar em “Copy (text)” no programa JavaFoil, clicar no botão
“Create Wing”, existente na worksheet “Calculation1”. Assim, será criada a imagem gráfica da
81
asa em estudo, bem como gravados os dados das coordenadas desta, na worksheet “Wing” do
mesmo subsistema.
Relativamente ao subsistema da propulsão, existe também uma ferramente destinada ao
estudo do motor e a melhor hélice para o mesmo. Para isso, é aberto o programa “JavaProp”
através do botão “Open Propeller Design” existente na worksheet “Calculation1” do workbook
“Propulsion”.
No subsistema “Assembly and Presentation” é feita a integração de todos os dados
provenientes dos outros subsistemas, determinando a existência, ou não, de descolagem por
parte da aeronave, usando o modelo de cálculo explicado anteriormente. A existência de
descolagem é possível ser avaliada através das imagens da Figura A.12.
Figura A.12 – Representação da existência ou não de descolagem.
Após determinados todos os valores neste subsistema, é possível listá-los para uma tabela à
parte, existente na worksheet “Layout_Results”, para existir uma preservação da evolução dos
resultados. Para tal, bastará clicar no botão existente na worksheet “Calculation1” denominado
“List Values”.
Após listados os valores, é de todo vantajoso analisá-los através de gráficos e, para tal, existe
um botão (Graph Creator), que abrirá uma janela para ser efectuada a selecção de variáveis a
analisar (Figura A.13).
Figura A.13– Janela “Show Graph”.
82
O gráfico criado é apresentado na worksheet “Layout_Results”, mas é também gravado em
forma de imagem na pasta “Charts” existente na mesma pasta dos ficheiros de sistema. As
imagens são gravadas em função da data e hora da sua criação.
Por fim, é também possivel visualizar a evolução das variáveis essenciais ao projecto da
aeronave para o air cargo, através de um gráfico em forma de “teia”, presente na worksheet
“Presentation”. Um exemplo deste gráfico está presente na Figura A.14.
Figura A.14 – Exemplo de um gráfico de evolução das varáveis de projecto.
As variáveis determinadas e colocadas como “outputs” e “inputs” dos respectivos subsistemas
para futuro uso pelos outros subsistemas, estão listadas na Tabela A.4.
83
Inputs Outputs
Aerodynamics
• Pi (¢) • Density (ρ)
• Maximum Lift Coefficient (�AáB)
• Reference Area (S) • Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (') • Lift induced drag coefficient (k) • Ground Lift Coefficient (��)
• Chord (c) • Wing Span (b) • Wing Profile
Propulsion
• Engine Model • Engine Weight (23) • Thrust (T ) • Engine Model
Avionics
• Receptor Weight • Servo Weight • Micro-Servo Weight • Number of Servos • Number of Micro-Servos • Battery Weight
Weight and Structure
• Receptor Weight • Servo Weight • Micro-Servo Weight • Number of Servos • Number of Micro-Servos • Engine Weight (23) • Battery Weight
• Total Weight of Empty Airplane
Assembly and Presentation
• Maximum Lift Coefficient (�AáB)
• Reference Area (S) • Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (') • Lift induced drag coefficient (k) • Ground Lift Coefficient (��)
• Thrust (T ) • Chord (c) • Wing Span (b) • Wing Profile • Engine Model
Tabela A.4 – Variáveis dos subsistemas colocadas como “Inputs” e “Outputs”, pelos respectivos subsistemas.
84
Annex B – Appendix to the Student Concurrent Design
Environment English Manual
B.1 – Introduction
This manual intends to be an appendix to the already existent English manual of student
concurrent design environment, provided by ESA.
Here will only be discuss the issues related to the Aircargo Challenge project design, developed
using the SCDE tool, which include the explanation of the calculation model, as well as the
explanation of the domains defined, and the operation mode of the new features added to the
SCDE.
B.2 – Aircargo Challenge
B.2.1 – Calculation Model
In this chapter it is explained the approaching mathematical modeling of the airplane take-off, to
be used in the Aircargo Challenge. At this point it will be assumed that the aerodynamics
surfaces have been designed by the aerodynamics engineers’ domain, as well as the engine
have been selected by propulsion engineer’s domain. The specific domains will be explained in
the next chapter. These assumptions are extremely important to provide essential parameters,
such as weight (W ), wing loading (S ), thrust (T ), maximum lift coefficient (C� á�) and others.
Fundamentally the take-off flight phase consists of accelerating from rest to take-off velocity,
)%&, and climbing to an altitude, which is greater than a reference obstacle height. The total
distance required to accomplish this is the take-off distance, #%&. However, in this project it will
be assumed that after reaching the take-off velocity, the airplane won’t have to climb to specific
altitude. Therefore, the take-off will be divided into two different parts: ground-roll and rotation
(Figure B.1).
Figure B.1 – Take-off distance.
The ground roll distance is designated #� , and is the portion where the airplane goes from rest
to )%&. After that, the rotation distance, #$, is the portion in which the airplane perfoms the
rotation maneuver, pitching up to increase the angle of attack.
The total take-off distance will be the sum of these two portions
#%& 7 #� 8 #$ .... (B.1)
85
The take-off velocity is calculated through the stall speed, )*+,--, which is affected by the wing
loading, and is defined as
)*+,-- 7 :;<
=> ?@AáB
CDE. (B.2)
Thus, the velocity required for take-off is defined as
)%&.//0 7 1,2)*+,-- 7 1,2 :;<
=> ?@AáB
CDE. (B.3)
The ground roll distance, is where the aircraft goes from rest, to take-off velocity. Therefore, the
ground distance must be evaluated by the acceleration
#� 7 I JK,L M) 7 N
= I OKEO,
KPQ.//0RKPQ.//0R (B.4)
with the acceleration is
� 7 S;PQ
∑ �� 7 S;PQ UV W � W ��X (B.5)
where �� is the rolling friction force, given by
�� 7 'Y2%& W ��Z. (B.6)
The Figure B.2 shows a schematic that indicates the forces acting on an aircraft during ground
roll. The rolling friction coefficient, ', varies with the runway, ' [ Y0,04; 0,08Z [5]. �� is the lift
generated during ground roll, and is based on an enhanced lift configuration for the wing, as
well as the angle attack produced when the aircraft is on the ground.
�� 7 �`��, (B.7)
where q is the dynamic pressure,
� 7 > KE= . (B.8)
Figure B.2 – Forces acting on an aircraft during ground roll.
Regarding the drag force (B.9), it is based on the drag coefficient, ��, and the lift-induced drag,
��.
86
� 7 �� 8 � ��=. (B.9)
To evaluate the ground distance, using (B.4), has first to be assumed that T/W is constant,
otherwise it would only be calculated if the integral is solved numerically by taking small velocity
time steps, where T/W is actually constant and equal to the maximum thrust at each upper time-
step value of velocity.
Then assuming, that T/W is constant, the acceleration results:
� 7 bN 8 b=)=, (B.10)
where
bN 7 c J %; W 'L (B.11)
and
b= 7 S >=Jd
e L f' �� W ��R W � ��g. (B.12)
Then:
#� 7 I hKE�Di�EKE
KPQ.//0R 7 N= �E j� k�Di�E KPQ.//0
E�D l. (B.13)
In the rotation distance, the aircraft angle of attack is increase until � 7 0,8�AáB. As a
convention, this is assumed to take three seconds. Therefore, since the velocity of the aircraft at
this point is )%&:
#$ 7 3)%&. (B.14)
However, since the result value is extremely high, has been defined the value of the rotation
distiance as #$ = 2 m.
Equation (B.3), defines the required take-off velocity for the aircraft. However, it might be useful,
having the track length, to calculate the speed reached at the end of the track.
Therefore, at this chapter it is assumed that the aircraft will take the entire track to take-off,
maximizing the weight that it is capable of transport.
From (B.13), it is possible to give the take-off velocity versus the take-off distance, and with a
constant value for thrust:
)%& 7 n�D�E
o�=�E*� W 1p . (B.15)
This take-off velocity value, allows the engineer to compare, at the end of the track, if the
aircraft has the required speed, calculated with (B.3), basically if the aircraft take-off with the
selected weight.
87
As well as it is possible to determine the take-off velocity, knowing the track length and the
available thrust, it is possible to calculate the required thrust to reach the take-off velocity at the
limit of the available track.
Using, again (B.13), and (B.11), to get the thrust value, it results
V 7 k)%&= b= NfqErEs�tNgS 8 'l 2. (B.16)
This calculation result can be used to identify if the propulsion system is efficient for the weight,
or even to know the thrust required and then choose the propulsion system.
However choosing the propulsion system, through the thrust value, requires several other
parameters, such as the thrust coefficient, �%, and the power coefficient, ��, that are specific
characteristics from the propeller:
�% 7 %>uE�v , (B.17) �� 7 �
>uw�x , (B.18)
where n is the propeller rotational velocity, D is the propeller diameter, and P the power transmit
from the motor.
The equation of the propeller efficiency is
�� 7 %{|}*+ �~�q| &}+5}+<{,�+ �~�q| �u5}+ 7 %K
� , (B.19)
where V, is the true airspeed, and the equation of the advanced ratio is
� 7 Ku�, (B.20)
which combined gives the thrust expression
V 7 �u�
?P?� . (B.21)
On the other hand, at the next chapter, at the propulsion domain will be presented an easy way
to determine both the coefficients and the thrust.
B.2.2 – Domains
To the Aircargo project design were created the subsystems domains present in the Table B.1.
At the table they are already assigned to their workstations.
88
Workstation 1
Server
Requirements, Costs & Air Conditions
Assembly & Presentation
Workstation 2 Aerodynamics
Workstation 3 Avionics
Workstation 4 Propulsion
Workstation 5 Weight & Structure
Table B.1– Workstations and their subsystems domains.
There are, in some domains, particular issues associated to them, that will be explained next.
In the aerodynamics domain there is a button (Open Wing Design) to open a tool called
“JavaFoil”, where wings could be created and where could be studied all aspects related to
them.
Using the coordinates data created by the tool it is possible to generate the wing in the
workbook of the aerodynamics domain. Therefore, after click in the “Copy (text)” button in the
JavaFoil program, the engineer should click in the button “Create Wing” existent in the
worksheet “Calculation1”. The wing will be generated at the “Wing” worksheet, and the
coordinates will also be saved there.
For the propulsion domain there is also a specific tool to perform the study of engine and
propeller system. The tool is the “JavaProp” and it is open clicking the button “Open Propeller
Design” existent at the worksheet “Calculation1” of the “Propulsion” workbook.
In the “Assembly and Presentation” subsystem is where the data integration, from all the other
subsystems, is done evaluating the existent of take off or not for the defined aircraft design.
Each time the values change, it will be automatically shown if it is possible to take off with the
existent data. It will be shown in one cell at the calculation worksheet “Take Off OK”, for a
possible take off and “No Take Off” if the existent values don’t allow the take off (Figure B.3).
Figure B.3 – Presentations of the calculation results, if there is take off or not.
Once the calculation in this workbook is done, it is possible to list the variable values in a table
existent at the worksheet “Layout_Results”. This allows to keep the evolution of the results. To
list the values, the engineer just needs to click the button “List Values” existent at the
“Calculation1” worksheet.
89
Once the variables values are all listed at the table it will be worth to analyze them through
charts. Therefore, there is a button called “Graph Creator” which open a menu (Figure B.4),
where the engineer could select the variables present in the chart.
Figure B.4 – Menu “Show Graph”.
The chart created will be presented in the “Layout_Resuts” worksheet, but it will also be saved
as an image at the “Charts” folder present at the same folder as the system files. The images
with the charts are saved in function of time and date of their creation.
Finally it is also possible to visualize the evolution of the essential variables to the project design
of the Aircargo aircraft, through a chart present in the “Presentation” worksheet. An example of
that chart is shown in the Figure B.5.
Figure B.5 – Example of one project design evolution results chart.
The variables defined as “outputs” and “inputs” of the all domains are presented at the Table
B.2.
90
Inputs Outputs
Aerodynamics
• Pi (¢) • Density (ρ)
• Maximum Lift Coefficient (�AáB)
• Reference Area (S) • Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (') • Lift induced drag coefficient (k) • Ground Lift Coefficient (��)
• Chord (c) • Wing Span (b) • Wing Profile
Propulsion
• Engine Model • Engine Weight (23) • Thrust (T ) • Engine Model
Avionics
• Receptor Weight • Servo Weight • Micro-Servo Weight • Number of Servos • Number of Micro-Servos • Battery Weight
Weight and Structure
• Receptor Weight • Servo Weight • Micro-Servo Weight • Number of Servos • Number of Micro-Servos • Engine Weight (23) • Battery Weight
• Total Weight of Empty Airplane
Assembly and Presentation
• Maximum Lift Coefficient (�AáB)
• Reference Area (S) • Aerodynamic Drag Coefficient (��)
• Rolling friction coefficient (') • Lift induced drag coefficient (k) • Ground Lift Coefficient (��)
• Thrust (T ) • Chord (c) • Wing Span (b) • Wing Profile • Engine Model
Table B.2 – Variables defined as “outputs” and “inputs” by each domain.
91
Annex C – JavaFoil
Figure C.1 – JavaFoil program window.
92
Annex D – JavaProp
Figure D.1 – JavaProp program window.
93
Annex E – Macro VBA Functions List Created
E.1. Present in all Subsystems Workbooks
Sub User_Login()
Private Sub WorkBook_Open()
Private Sub CommentAdd_Calculation1_Click()
Private Sub CommentAdd_Administration_Click()
Private Sub Delete_Comment_Administration_Click()
Private Sub CommentAdd_Requirements_Click()
Private Sub CommentAdd_Presentation_Click()
Private Sub CommentAdd_Outputs_Click()
Private Sub CommentAdd_Components_Click()
Private Sub CommentAdd_Inputs_Click()
Private Sub CommentAdd_RequestByMe_Click()
Private Sub CommentAdd_RequestToMe_Click()
Forms:
UserLoginForm – including:
Private Sub Ok_Click()
Private Sub txtUser_Change()
InsertComment – including:
Private Sub Cancel_Click()
Private Sub Ok_Click()
Private Sub txtComment_Change()
Private Sub Help_Click()
DeleteCommentForm – including:
Private Sub Cancel_Click()
Private Sub UserForm_Initialize()
Private Sub Delete_Click()
Private Sub Help_Click()
94
E.2. Aerodynamics
Private Sub Alongamento_Click()
Private Sub Factor_Arrasto_Induzido_Click()
Private Sub Open_JavaFoil_Click()
Private Sub Var_Ref_Click()
Private Sub Wing_Create_Click()
Private Sub WingCreator_Wing_Click()
Forms:
AlongamentoForm – including:
Private Sub Ok_Click()
FactorArrastoForm – including:
Private Sub Ok_Click()
JavaFoilForm – including:
Private Sub No_Click()
Private Sub Yes_Click()
VarRefForm – including:
Private Sub Ok_Click()
WingForm – including:
Private Sub No_Click()
Private Sub Yes_Click()
E.3. Propulsion
Private Sub Propeller_Design_Open_Click()
Forms:
JavaPropForm – including:
Private Sub No_Click()
Private Sub Yes_Click()
E.4. Assembly and Presentation
Private Sub Calc_Thrust_Click()
Private Sub Calc_Track_Click()
95
Private Sub Calc_VStall_Click()
Private Sub Calc_VTO_Click()
Private Sub Calc_VTONeed_Click()
Private Sub Listar_Click()
Private Sub CommentAdd_Layout_Results_Click()
Private Sub GraphCreator_Click()
Sub Chart_Creator()
Sub List_Values()
Forms:
Calc_F1Form – including:
Private Sub Ok_Click()
Calc_F2Form – including:
Private Sub Ok_Click()
Calc_ThrustForm – including:
Private Sub Ok_Click()
Calc_TrackForm – including:
Private Sub Ok_Click()
Calc_VStallForm – including:
Private Sub Ok_Click()
Calc_VTOForm – including:
Private Sub Ok_Click()
Calc_VTONeedForm – including:
Private Sub Ok_Click()
ShowGraphForm – including:
Private Sub Cancel_Click()
Private Sub DrawGraph_Click()
Private Sub Help_Click()