Advise, Formalize and Integrate MDO Architectures
A Methodology and Implementation
Hoogreef, Maurice
DOI
10.4233/uuid:cc2af611-6d78-4439-9b10-7e62ae579029
Publication date
2017
Document Version
Final published version
Citation (APA)
Hoogreef, M. (2017). Advise, Formalize and Integrate MDO Architectures: A Methodology and
Implementation. https://doi.org/10.4233/uuid:cc2af611-6d78-4439-9b10-7e62ae579029
Important note
To cite this publication, please use the final published version (if applicable).
Please check the document version above.
Copyright
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy
Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim.
This work is downloaded from Delft University of Technology.
A
RCHITECTURES
A M
ETHODOLOGY AND
I
MPLEMENTATION
Proefschrift
ter verkrijging van de graad van doctor aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus prof. ir. K.C.A.M. Luyben, voorzitter van het College voor Promoties,
in het openbaar te verdedigen op vrijdag 7 juli 2017 om 10:00 uur
door
Maurice Frederik Maria H
OOGREEF
Ingenieur Luchtvaart en Ruimtevaart, Technische Universiteit Delft geboren te Haarlem, Nederland
copromotor: Dr. ir. G. La Rocca Samenstelling promotiecommissie:
Rector Magnificus, voorzitter
Prof. dr. ir. L.L.M. Veldhuis, Technische Universiteit Delft
Dr. ir. G. La Rocca, Technische Universiteit Delft
Onafhankelijke leden:
Prof. dr. I. Horvath Technische Universiteit Delft
Prof. dr. R. Curran Technische Universiteit Delft
Prof. dr. J.J. Alonso Stanford University, Verenigde Staten
Dr.-Ing. T. Zill, Deutsches Zentrum für Luft- und Raumfahrt, Duitsland
Overige leden:
R. d ’ Ippolito (MSc), Noesis Solutions N.V., België
This research was partially funded by the iProd project from the European Community Seventh Framework Programme FP7/2007-2013 under grant agreement number 257657 and by the European ITEA2 project IDEaliSM (#13040) as part of the Eureka cluster pro-gramme.
Copyright © 2017 by M.F.M. Hoogreef
All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage and retrieval system, without prior written permission from the author.
Cover: © 2017 by M.F.M. Hoogreef ISBN 978-94-028-0682-3
Printed by: Ipskamp Printing
An electronic version of this dissertation is available at
Marianne & Frits
und für Friedhelm†
C
Nomenclature ix Summary xiii Samenvatting xvii Zusammenfassung xxi 1 Introduction 11.1 Problems with MDO application and research objective . . . 4
1.2 Potential solution: InFoRMA - Integration, Formalization and Recommen-dation of MDO architectures . . . 6
1.2.1 InFoRMA - description of the potential solution. . . 7
1.2.2 Expert systems for optimization and research context. . . 8
1.2.3 Perspectives on MDO problem formulations. . . 10
1.2.4 Aim of this thesis. . . 11
1.3 Outline of the thesis. . . 12
2 Multidisciplinary Design Optimization: Theoretical background and current implementation 15 2.1 The origins of MDO as a self-standing discipline . . . 15
2.2 Definition of an MDO problem . . . 19
2.3 MDO architectures and the XDSM . . . 20
2.3.1 The extended design structure matrix . . . 21
2.3.2 MDO architectures. . . 22
2.4 MDO frameworks and simulation workflows . . . 23
2.4.1 Simulation workflows and Simulation Workflow Management. . . . 24
2.4.2 Framework Requirements . . . 25
2.4.3 Examples of PIDO tools . . . 26
2.4.4 Commonalities and missing capabilities of PIDO software. . . 29
2.5 Outlook for solutions to MDO challenges. . . 30
2.5.1 Supporting MDO in engineering design: the IDEaliSM project. . . . 31
2.5.2 AGILE . . . 32
2.6 Requirements and use cases to support MDO application . . . 33
2.6.1 Requirements to support MDO application . . . 33
2.6.2 Use cases to support MDO application. . . 34
3 Integration, Formalization and Recommendation of MDO Architectures 39 3.1 InFoRMA and its functionalities. . . 40
3.1.1 Project setup and problem modeling . . . 43
3.1.3 Formalize . . . 48
3.1.4 Integrate. . . 49
3.2 Components of the InFoRMA prototype implementation. . . 50
3.3 Summary. . . 54
4 Selection of suitable MDO architectures 57 4.1 Selection criteria for MDO architectures . . . 58
4.2 Ranking of MDO architectures . . . 66
4.3 Summary. . . 69
5 Introduction and expected benefits of Semantic Web technologies 71 5.1 Terminology & basic definitions. . . 71
5.2 Ontologies . . . 73
5.3 Reasoning. . . 75
5.4 Rules . . . 79
5.5 Databases and structured querying. . . 80
5.5.1 SPARQL querying . . . 80
5.5.2 Triplestores . . . 81
5.5.3 Combining triplestores, semantic queries and ontologies . . . 83
5.6 Summary & Benefits of Semantic Web technologies for InFoRMA. . . 84
6 Semantic Web technologies to support MDO 85 6.1 The role of Semantic Web technologies to formalize and advise MDO ar-chitectures . . . 85
6.2 MDO ontologies, their elements and modeling approaches. . . 88
6.2.1 Upper ontology and ontology imports. . . 88
6.2.2 Ontology for MDO Architectures. . . 91
6.2.3 Mathematical classification ontology . . . 103
6.3 Decision support for MDO architectures . . . 106
6.3.1 Problem characteristics ontology and rule modeling. . . 106
6.3.2 Rule definition. . . 106
6.3.3 Rule modification outside of source-code and ontology . . . 108
6.3.4 Rules to advise on MDO architectures . . . 109
6.4 Supporting MDO problem formalization through reasoning and structured querying . . . 111
6.5 Summary. . . 114
7 MDO problem definition and formalization 115 7.1 Human readable representations of formalized MDO problems . . . 117
7.1.1 Modifications to XDSM representations of MDO architectures. . . . 119
7.1.2 Notes on XDSM readability . . . 130
7.2 Problem formalization: From N2to MDO architecture . . . 130
7.3 Outlook: Schema for the exchange of MDO architecture and simulation workflow information. . . 137
8 Automatic MDO simulation workflow generation 139
8.1 Challenges in workflow generation . . . 139
8.2 Simulation workflow modeling . . . 141
8.2.1 Simulation workflow ontologies . . . 141
8.2.2 Simulation workflow modeling for disciplinary analyses. . . 146
8.3 Automatic simulation workflow (re)generation . . . 148
8.3.1 Additional information for simulation workflow generation. . . 150
8.3.2 Materialization of disciplinary workflows . . . 150
8.3.3 MDO architecture workflow generation . . . 152
8.4 Summary. . . 156
9 Case studies part I: Advise, Formalize & Integrate - Sellar problem & Aircraft wing optimization 159 9.1 Analytical example: the Sellar problem . . . 160
9.1.1 Problem definition. . . 160
9.1.2 Architecture advice, problem formalization and workflow integra-tion . . . 161
9.1.3 Verification of the generated architecture workflows and optimiza-tion results. . . 169
9.1.4 Validation of the MDO architecture advice. . . 171
9.2 MDO example: Aircraft wing optimization . . . 173
9.2.1 Problem definition. . . 173
9.2.2 Architecture advice, problem formalization and workflow integra-tion . . . 176
9.2.3 Verification of the generated architecture workflows and optimiza-tion results. . . 182
9.2.4 Validation of the MDO architecture advice. . . 182
9.3 Discussion . . . 184
10Case Studies part II: Formalize & Integrate - Hinge Design and Optimization 187 10.1Problem definition for hinge optimization . . . 190
10.1.1 Problem modeling in InFoRMA . . . 192
10.1.2 Problem formalization and integration . . . 192
10.2Analysis of results. . . 197
10.3Discussion . . . 198
11Conclusions and Recommendations 201 11.1Conclusions. . . 202
11.2Recommendations and directions for future research. . . 207
References 209 A Overview of common MDO Architectures 219 A.1 Monolithic architectures . . . 219
A.1.1 All At Once (AAO) . . . 219
A.1.2 Simultaneous Analysis and Design (SAND) . . . 220
A.1.3 Individual Disciplinary Feasible (IDF) . . . 221
A.2 Distributed architectures . . . 224
A.2.1 Concurrent Sub-Space Optimization (CSSO). . . 224
A.2.2 Collaborative Optimization (CO). . . 226
A.2.3 Enhanced Collaborative Optimization (ECO) . . . 227
A.2.4 Bi-Level Integrated System Synthesis (BLISS) . . . 228
B iProd: Integrated management of product heterogeneous data 231 B.1 The iProd project framework . . . 231
B.1.1 Relating product structure, requirements and tests: the correlation matrix . . . 234
B.2 The correlation matrix featuring Semantic Web technologies. . . 235
B.3 Applications of Semantic Web technology in iProd . . . 241
C Generated XDSMs for Sellar problem 243 D Results from optimization studies and reference material 251
Acknowledgements 259
N
Acronyms
AAO All At Once
AI Artificial Intelligence
AIAA American Institute for Aeronautics and Astronautics
AIF Advanced Integration Framework
API Application Programming Interface
BLISS Bi-Level Integrated System Synthesis
CMDOWS Common MDO Workflow Schema
CO Collaborative Optimization
CSSO Concurrent Sub-Space Optimization
CST Class function / Shape function Transformation technique
CWA Closed World Assumption
DOE Design Of Experiments
DSM Design Structure Matrix
ECO Enhanced Collaborative Optimization
EL Engineering Library
ELW Engineering Language Workbench
GUI Graphical User Interface
HES High-Level Engineering Services
HLA High-Level Activities
IATA International Air Transport Association
IDF Individual Discipline Feasible
IRI Internationalized Resource Identifier
JSON JavaScript Object Notation
KB Knowledge Base
KBS Knowledge Based System
MDA MultiDisciplinary Analysis
MDF MultiDisciplinary Feasible
MDO Multidisciplinary Design Optimization
MTOW Maximum Take-Off Weight
NASA National Aeronautics and Space Administration
OWA Open World Assumption
OWL Web Ontology Language
PDP Product Development Process
PIDO Process Integration and Design Optimization
RDF Resource Description Framework
RDFS RDF Schema
SAND Simultaneous Analysis aNd Design
SPARQL SPARQL Protocol And RDF Query Language
SQP Sequential Quadratic Programming
SWFM Simulation WorkFlow Management
SWRL Semantic Web Rule Language
TC-MDO Technical Committee for Multidisciplinary Design Optimization
URI Uniform Resource Identifier
W3C World Wide Web Consortium
XDSM eXtended Design Structure Matrix
XML eXtensible Markup Language
Latin Symbols
b Span [m]
CST CST coefficient [−]
c Design constraints vector [−]
cc Consistency constraints vector [−]
c Chord [m]
˜c Vector with linear model of non-local constraints [−]
CD Drag coefficient [−]
CL Lift coefficient [−]
CT Specific fuel consumption [N /N s]
D Drag force [N ]
do Outer diameter [m]
f Objective function [−]
ft ank Factor to account for structural elements, fuel systems, etc. in fuel tank[−]
Ji Discipline i objective to minimize inconsistency [−]
J∗
i Interdisciplinary compatibility constraint of discipline i, represented by
disciplinary objective Ji [−]
L Lift force [N ]
mat Material ID for standard materials [−]
MS Margin of safety [−]
R Vector of residual form of disciplinary analysis equations [−]
R Range [m]
S Wing planform area [m2]
sj Slack variables vector [−]
tf Thickness factor [−]
V Cruise speed [m/s]
v Volume [m3]
W Weight [N ]
x Design variables vector [−]
ˆx0i Vector of shared design variable copies, passed (by the system optimizer)
to and manipulated by discipline i [−]
ˆxi Vector of copies of disciplinary design variable [−]
y Coupling (response) variables vector [−]
ˆy Coupling variable copies (target variables) vector [−]
¯y State variables vector [−]
˜y Vector of surrogates for coupling variables [−]
Greek Symbols
λ Taper ratio [−]
Λ Sweep angle [◦]
φ Twist angle [◦]
ρ Density [kg /m3]
ωC i Weight factor for system consistency [−]
Subscripts
A−W Aircraft minus wing
C eLug Central Lug C LLug Clevis Lug
d es Design condition f uel Fuel max Maximum st r Structure T O Take-off condition w i ng Wing
0 Shared by all disciplines
cr Cruise condition
i Specific to local discipline i
j Specific to non-local discipline j
k Kink LE Leading edge r Root r e f Reference t Tip
Superscripts
∗ LinearizationOther Symbols
∧ Notation for “AND”
≡ Notation for “is equivalent to”
→ Notation for “implies”
S
For decades, engineers have been pursuing improvements in aircraft design disciplines, such as aerodynamics, structures and performance, and in the methods to deal with their interactions. This has allowed modern-day commercial transport aircraft to achieve,
for example, fuel efficiencies that have more than doubled[1] (Boeing 707 vs 787).
How-ever, due to the increasingly challenging environmental requirements and the growing interest in novel and more integrated configurations, such as blended-wing bodies and box-wing aircraft, the ability to deal with and exploit complex multidisciplinary interac-tions is becoming a key factor to sustain innovation.
Multidisciplinary design optimization (MDO)is a methodology that enables the incor-poration and exploitation of disciplinary interactions, already during the conceptual de-sign phase. It does so by means of dedicated mathematical formulations and structured computation strategies, thereby aiding designers in the improvement of existing solu-tions and the development of innovative/unconventional designs.
However, the potential of MDO has not yet been fully exploited in industry. Its bene-fits have been demonstrated mainly on academic problems, by experts in optimization. There are several causes that, so far, have limited the widespread use of MDO in industry: 1. lack of adequately flexible, accurate and robust parametric models to support MDO
using high-fidelity simulations
2. limited availability of computational resources to solve complex problems of in-dustrial interest
3. intrinsic complexity of the process to translate a “real case” multidisciplinary prob-lem into a correct MDO formulation
4. lack of awareness and understanding of the many established MDO architectures (i.e. the formal strategies to organize and coordinate the various components of an MDO system, such as its disciplinary blocks, the optimizer(s) and the various objective and constraint functions) and their specific suitability to solve problems of different nature
5. complex, lengthy and error-prone process to integrate (even well-) formalized MDO problems (according to a specific MDO architecture) into an executable MDO frame-work to run the actual optimization
The first issue is being well addressed, from one side, by the more widespread use of knowledge-based parametric CAD (Computer Aided Design) tools and Knowledge Based
Engineering (KBE) applications, and from the other side, by the increasing level of flexi-bility and robustness of new generation high-fidelity analysis tools and their preproces-sors. The second issue is being addressed by “massively parallel computing”, although the increased availability of computational resources tends to increase the demand for even more computations.
For the last three issues, however, there is not yet an adequate solution, although it is necessary to lower the MDO entry level in industry and provide adequate support to its current practitioners.
To this purpose, a methodology is being proposed in this research work, together with a prototype software implementation to verify its merit, with the objective to support both experienced and novel MDO users. The result is InFoRMA, which stands for
Integra-tion, Formalization and Recommendation of MDO Architectures. InFoRMA performs the following three main activities:
1. Advise: to assist a user with the formal definition of the MDO problem to be solved (specification of disciplines, constraints, objectives, design variables, parameters, etc.); to assess the problem at hand, and, on the basis of specific user require-ments, suggest a suitable MDO architecture
2. Formalize: to provide a way to automatically represent an MDO problem accord-ing to a selected architecture’s definition and to store it in a neutral representation (format)
3. Integrate: to automatically integrate the formalized problem in a simulation work-flow, which can be translated to a PIDO (Process Integration and Design Optimiza-tion) tool’s specific implementation
Several PIDO systems are indeed available on the market, which possibly represent the most widespread and convenient type of software tools to set-up simulation and opti-mization workflows. These systems can manage variables and connections to external analysis software and offer access to various optimization algorithms. Yet, most of them do not provide any support in the assembly of MDO problems according to formal MDO architectures. Besides that, setting up a workflow always demands a large amount of manual, tedious and error prone operations through the PIDO tool’s user interface. A novel MDO user, who understands the problem at hand, yet is seeking support to ap-ply optimization, particularly struggles with the definition of the MDO problem and the formalization according to a suitable architecture, thus can benefit from all InFoRMA capabilities. An experienced MDO user, who is well aware of the most convenient archi-tectures to apply, is typically frustrated by the complicated and time-consuming process required to set-up the computation workflow in the PIDO tool at hand. The experienced MDO user would want a quick and correct implementation in the PIDO system, and make use of the saved time to test different MDO architectures. Such a user would par-ticularly benefit from the formalize and integrate capabilities.
The technical implementation of InFoRMA relies on Semantic Web technologies. These technologies allow for the addition of meaning (semantics) to data, which can be pro-cessed by a computer. Core elements of these Semantic Web technologies are
ontolo-gies: formal representations of domain knowledge which can be used to model types of
objects or concepts, their properties and the relationships between them. These ontolo-gies serve as the data model and data structure for MDO architectures, hence providing templates which can be used for the automatic formalization and integration. The com-bination of semantic querying and a light form of reasoning on top of these ontologies provided a significant benefit in terms of performance, reliability, reusability and devel-opment effort in a practical application.
Although the automatic workflow implementation has been demonstrated for a com-mercial PIDO tool (Noesis Solutions – Optimus), the developed ontologies for MDO ar-chitectures and their formal translation in simulation workflows have resulted in the def-inition of a prototype neutral exchange format for MDO problem information. This can be seen as a vendor and implementation neutral format, which contains all relevant information of an MDO problem according to a particular MDO architecture, without the specific implementation details of the targeted PIDO tool. Such a neutral represen-tation is not only the starting point to translate a given MDO workflow in some PIDO tool, but also the data source used by InFoRMA for the automatic generation of XDSMs, the popular extension of the classic Design Structure Matrix method to graphically illus-trate the structure of any MDO problem.
InFoRMA has been applied to a set of case studies, ranging from simple analytical prob-lems to (industrial) aeronautical probprob-lems of representative complexity. These studies have demonstrated:
• the ability to perform automatic formalization of MDO problems by means of
eight common MDO architectures, including single and multilevel ones
• the ability to reduce the setup time of any MDO workflow from hours to minutes;
in the case of one industrial problem, a time reduction of 90% was achieved for the correct setup of the problem according to the MDF architecture.
• The capability to advise MDO architectures, given the current state of the ontology
and reasoning system, has demonstrated limited benefit and suitability to address complex MDO problems.
S
Al tientallen jaren streven ingenieurs verbeteringen na in de verschillende disciplines van het vliegtuigontwerp, zoals aerodynamica, structuren en prestaties, en naar verbe-tering in de methodes om met de interacties tussen deze disciplines om te gaan. Dit heeft er bijvoorbeeld toe geleid dat hedendaagse commerciële transportvliegtuigen een
twee keer zo hoge brandstofefficiëntie hebben bereikt[1] ten opzichte van de
beginda-gen van commerciële vluchten met straalvliegtuibeginda-gen (Boeing 707 vs 787). Echter, door steeds strengere milieueisen, en de groeiende belangstelling voor nieuwe en meer geïn-tegreerde vliegtuigconfiguraties, zoals de “blended-wing-body” en “box-wing” vliegtui-gen, wordt het omgaan met en uitbuiten van complexe multidisciplinaire interacties een steeds belangrijkere factor om te blijven innoveren.
Multidisciplinairy design optimization (MDO)is een methodiek die de integratie en ex-ploitatie van de disciplinaire interacties mogelijk maakt, al tijdens de conceptuele ont-werpfase. Door middel van speciale wiskundige formules en gestructureerde bereke-ningsstrategieën worden ontwerpers geholpen bij het verbeteren van bestaande oplos-singen en het ontwikkelen van innovatieve/onconventionele ontwerpen.
De potentie van MDO is nog niet volledig benut in de industrie. De voordelen zijn veelal aangetoond op basis van academische problemen, door optimalisatie-experts. Er zijn verschillende oorzaken die tot nu toe echter het wijdverbreid gebruik van MDO in de industrie beperken:
1. een gebrek aan voldoende flexibele, accurate en robuuste parametrische modellen om MDO te ondersteunen met behulp van accurate hogere orde simulaties; 2. de beperkte beschikbaarheid van rekenkracht om complexe industriële
proble-men op te lossen;
3. de intrinsieke complexiteit van het proces om een “echt” multidisciplinair pro-bleem in een correcte MDO formulering te vertalen;
4. het gebrek aan kennis en begrip van de vele bekende MDO architecturen (i.e. de formele strategieën om de verschillende onderdelen van een MDO-systeem te or-ganiseren en te coördineren, zoals de disciplines, de optimizer(s) en de verschil-lende optimalisatie criteria en randvoorwaarden) en de specifieke geschiktheid van deze architecturen om verschillende soorten problemen op te lossen;
5. het complexe, langdurige en foutgevoelige proces om (zelfs goed) geformaliseerde MDO problemen (volgens een specifieke MDO architectuur) te integreren in een uitvoerbare MDO implementatie om de daadwerkelijke optimalisatie uit te voe-ren.
Het eerste punt wordt inmiddels opgelost door, aan de ene kant, het toenemende ge-bruik van op kennis gebaseerde parametrische “Computer Aided Design” (CAD) soft-ware en “Knowledge Based Engineering” (KBE) applicaties, en aan de andere kant, door de toenemende flexibiliteit en robuustheid van de nieuwe generatie hoge nauwkeurig-heid analyse-instrumenten en hun preprocessors. Het tweede punt wordt opgelost door “massively parallel computing”, hoewel de toegenomen beschikbaarheid van rekenkracht de neiging heeft om de vraag naar nog meer berekeningen steeds weer te verhogen. Voor de laatste drie punten is er echter nog geen adequate oplossing, alhoewel het nood-zakelijk is om de drempel van MDO gebruik in de industrie te verlagen, door adequate ondersteuning van de huidige gebruikers.
In dit onderzoek wordt een methodiek voorgesteld, alsmede een prototype software-implementatie ter controle van deze methodiek, met als doel zowel ervaren als nieuwe MDO gebruikers te ondersteunen. Het resultaat is InFoRMA, wat staat voor Integration,
Formalization and Recommendation of MDO Architectures. InFoRMA beschikt over de volgende drie hoofdfunctionaliteiten:
1. Advies: het assisteren van een gebruiker met de formele definitie van het op te lossen MDO probleem (specificatie van disciplines, randvoorwaarden, optimali-satiecriteria, ontwerpvariabelen, parameters, etc.); het classificeren van het op te lossen probleem en, op basis van de specifieke behoeften van de gebruiker, sug-gesties doen voor een geschikte MDO architectuur;
2. Formalisatie: het automatisch weergeven van een MDO probleem volgens de de-finitie van een gekozen architectuur en het op te slaan in een neutrale representa-tie (format);
3. Integratie: het geformaliseerde probleem automatisch integreren in een simulatie workflow, die vertaald kan worden naar een specifieke implementatie in een PIDO (Process Integration and Design Optimization) tool.
Er zijn verschillende PIDO systemen op de markt, die mogelijk de meest voorkomende en handigste soort software tools is voor de set-up van simulatie en optimalisatie work-flows. Deze systemen kunnen variabelen en connecties naar externe analyse software beheren en zij bieden verschillende optimalisatie algoritmes aan. Desalniettemin bie-den de meeste systemen geen ondersteuning in het opzetten van MDO problemen op basis van formele MDO architecturen. Daarnaast vraagt het opzetten van een simula-tie workflow altijd een grote hoeveelheid aan handmatige, langdradige en foutgevoelige handelingen via de gebruikersinterface van PIDO systemen.
Een nieuwe MDO gebruiker, die het optimalisatieprobleem begrijpt, maar op zoek is naar ondersteuning voor het toepassen van optimalisatie, worstelt met name met de de-finitie van een MDO probleem en de formalisatie volgens een geschikte architectuur. Dit type gebruiker profiteert van alle functionaliteiten van InFoRMA. Een ervaren MDO
ge-bruiker, die goed op de hoogte is van de meest geschikte architecturen, wordt meestal gefrustreerd door het ingewikkelde en tijdrovende proces dat nodig is om een workflow in de beschikbare PIDO software op te zetten. De ervaren MDO gebruiker zou een snelle
en correcte implementatie van het probleem willen in de PIDO software, om zo de be-spaarde tijd te kunnen gebruiken om verschillende MDO architecturen te testen. Dit type gebruiker zou met name profiteren van de formalisatie en integratie functionalitei-ten.
De technische implementatie van InFoRMA berust op het gebruik van Semantic
Web-technologieën. Deze technologieën maken het mogelijk om betekenis (semantiek) aan data toe te voegen, die door een computer kan worden verwerkt. Belangrijke elemen-ten van deze Semantic Web-technologieën zijn ontologieën: formele representaties van domein specifieke kennis. Deze kunnen worden gebruikt om soorten objecten of con-cepten, hun eigenschappen en onderlinge relaties te modelleren. Deze ontologieën die-nen als datamodel en gegevensstructuur voor MDO architecturen, zodat zij als templates kunnen worden gebruikt voor de automatische formalisatie en integratie. De combina-tie van semantische “queries” en een beperkte vorm van “reasoning” op basis van deze ontologieën, boden een significant voordeel in termen van de prestaties, betrouwbaar-heid, herbruikbaarheid en ontwikkelingsinspanning in een praktische toepassing. Hoewel de automatische workflow implementatie is aangetoond voor commerciele PIDO software (Noesis Solutions - Optimus), hebben de ontwikkelde ontologieën voor MDO architecturen en hun formele vertaling in de simulatie workflows geresulteerd in de de-finitie van een prototype neutraal uitwisselingsformat voor de informatie van MDO
problemen. Dit kan worden gezien als een implementatie-neutraal format, dat alle rele-vante gegevens van een MDO probleem, volgens een bepaalde MDO architectuur bevat, zonder de specifieke details van de implementatie in specifieke PIDO software. Een der-gelijke neutrale representatie is niet alleen het uitgangspunt voor de vertaling van een MDO workflow naar PIDO software, maar is ook de gegevensbron voor het automatisch genereren van XDSMs, de populaire uitbreiding van de klassieke “Design Structure Ma-trix” methode voor de grafische weergave van de structuur van elk MDO probleem. InFoRMA is toegepast op een reeks van case studies, variërend van eenvoudige ana-lytische problemen tot (industriële) aeronautische problemen van een representatieve complexiteit. Deze studies hebben het volgende aangetoond:
• de mogelijkheid om een automatische formalisatie van MDO problemen uit te
voeren voor acht gebruikelijke MDO architecturen, waaronder single- en multil-evel architecturen;
• de mogelijkheid tot het verminderen van de setup-tijd van een MDO workflow
van uren tot minuten; bij een industrieel probleem werd een reductie van 90% bereikt voor de correctie implementatie van het probleem volgens de MDF archi-tectuur.
• De mogelijkheid om advies voor MDO architecturen te geven, gezien de huidige
stand van de ontologieën en de “reasoning” software, heeft een beperkt voordeel en een beperkte geschiktheid voor het aanpakken van complexe MDO problemen aangetoond.
Z
Seit Jahrzehnten versuchen Ingenieure die verschiedenen Disziplinen des Flugzeugent-wurfes, wie Aerodynamik, Konstruktion und Flugleistung, und die Methoden um mit ih-ren Wechselwirkungen umzugehen, zu verbessern. Dies ermöglicht den heutigen kom-merziellen Transportflugzeugen zum Beispiel eine Effizienz beim Kraftstoffverbrauch zu
erzielen, die mehr als doppelt so hoch ist [1] (Boeing 707 vs 787). Aufgrund der stets
an-spruchsvolleren Umweltanforderungen und des wachsenden Interesses an neuartigen und integrierten Flugzeugkonfigurationen, wie “blended-wing-bodies” und “box-wing” Flugzeugen, wird die Fähigkeit um komplexe multidisziplinäre Wechselwirkungen zu er-fassen und zu nutzen, ein wichtiger Faktor um Innovation zu ermöglichen.
Multidisciplinary design optimization(MDO) ist eine Methodik, die Integration und Ausnutzung von disziplinären Interaktionen bereits während des konzeptionellen Ent-wurfstadiums ermöglicht. Dies geschieht durch spezielle mathematische Formulie-rungen und strukturierte Berechnungsstrategien und sie unterstützt somit Designer bei der Verbesserung bestehender Entwürfe und der Entwicklung innovativer/unkonventio-neller Konzepte.
Das Potenzial von MDO ist jedoch in der Industrie noch nicht völlig ausgenutzt. Deren Vorteile wurden vor allem bei akademischen Problemen, von Optimierungsexperten de-monstriert. Es gibt verschiedene Ursachen, die bislang die weit verbreitete Verwendung von MDO in der Industrie eingeschränkt haben:
1. fehlende adäquate, flexible, präzise und robuste parametrische Modelle zur Un-terstützung von MDO mit High-Fidelity-Simulationen
2. limitierte Verfügbarkeit von Berechnungsressourcen zur Lösung komplexer Pro-bleme des industriellen Interesses
3. intrinsische Komplexität des Prozesses um ein realistisches multidisziplinäres Pro-blem in eine korrekte MDO-Formulierung zu übersetzen
4. fehlendes Bewusstsein und Verständnis der vielen etablierten MDO-Architekturen (i.e. die formalen Strategien zur Organisation und Koordination der verschiedenen Komponenten eines MDO-Systems, wie seine Disziplinarblöcke, die Optimizers und die verschiedenen Objektiv- und Einschränkungs-Funktionen) und ihre spe-zifische Eignung für unterschiedliche Probleme
5. komplexe, zeitraubende und fehleranfällige Prozesse zur Integration formalisier-ter MDO-Probleme (nach einer bestimmten MDO-Architektur) in ein ausführba-res MDO-Framework, um die eigentliche Optimierung durchzuführen.
Das erste Problem wird auf der einen Seite durch die weit verbreitete Nutzung von wis-sensbasierten parametrischen “Computer Aided Design” (CAD) Tools und “Knowledge Based Engineering” (KBE) Anwendungen erreicht und auf der anderen Seite durch die zunehmende Flexibilität und Robustheit der neuen Generation “High-Fidelity-Analyse-Tools” und ihre Präprozessoren. Das zweite Problem wird durch “massive parallel com-puting” angesprochen, obwohl die erhöhte Verfügbarkeit von Berechnungsressourcen dazu neigt, die Nachfrage nach noch mehr Berechnungen zu erhöhen.
Für die letzten drei Probleme gibt es jedoch noch keine adäquate Lösung, obwohl es not-wendig ist, das Einstiegsniveau in der Industrie zu senken und derzeitigen MDO-Praktikern angemessene Unterstützung zu bieten.
Zu diesem Zweck wird in dieser Doktorarbeit eine Methodik vorgeschlagen, zusammen mit einer Prototyp-Software-Implementierung zur Überprüfung der Methodik, mit dem Ziel, sowohl erfahrene als auch neue MDO-Nutzer zu unterstützen. Das Ergebnis ist
InFoRMA: Integration, Formalisierung und Empfehlung von MDO-Architekturen. In-FoRMA bietet die folgenden drei Hauptfunktionalitäten:
1. Beratung: um einen Nutzer mit der formalen Definition des zu lösenden MDO-Problems zu unterstützen (Spezifikation von Disziplinen, Einschränkungen, Zie-len, EntwurfsvariabZie-len, Parametern usw.); zur Klassifizierung des Problems und auf Grund spezifischer Benutzeranforderungen eine geeignete MDO-Architektur vorzuschlagen
2. Formalisierung: um eine Methode zu bieten automatisch ein MDO-Problem nach einer ausgewählten Architekturdefinition darzustellen und es in einer neutralen Darstellung (Format) zu speichern
3. Integration: um das formalisierte Problem automatisch in einen Simulations-Work-flow zu integrieren, der in eine spezifische PIDO (Process Integration and Design Optimization) Implementierung übersetzt werden kann.
Mehrere PIDO-Systeme sind verfügbar, welche die am meist verbreiteste und bequems-te Art von Software-Tools zur Einrichtung von Simulations- und Optimierungs-Workflows darstellen. Diese Systeme können Variablen und Verbindungen zu externer Analysesoft-ware steuern und bieten Zugriff auf verschiedene Optimierungsalgorithmen. Dennoch bieten die meisten PIDO-Systeme keine Unterstützung bei der Zusammenstellung von MDO-Problemen nach formalen MDO-Architekturen. Darüber hinaus erfordert die Ein-richtung eines Workflows immer eine große Menge an manuellen, zeitraubenden und fehleranfälligen Handlungen über die Benutzeroberfläche des PIDO-Tools.
Ein neuer MDO-Nutzer, der das Optimierungsproblem versteht, sucht trotzdem Unter-stützung bei der tatsächlichen Optimierung, insbesondere bei der Definition des MDO-Problems und der Formalisierung nach einer geeigneten Architektur und kann somit von allen InFoRMA-Funktionalitäten profitieren. Ein erfahrener MDO-Nutzer, der sich der geeignetesten Architekturen bewusst ist, ist in der Regel frustriert durch den kom-plizierten und zeitaufwändigen Prozess, der für die Einrichtung des Berechnungswork-flows ins PIDO-Tool erforderlich ist. Der erfahrene MDO-Nutzer möchte eine schnelle
und korrekte Implementierung ins PIDO-System und die gewonnene Zeit nutzen, ver-schiedene MDO-Architekturen zu testen. Ein solcher Nutzer würde vor allem von den Formalisierungs- und Integrationsfunktionalitäten profitieren.
Die technische Umsetzung von InFoRMA basiert auf Semantic Web technologies. Die-se Technologien ermöglichen die Ergänzung von Daten durch Bedeutung (Semantik), die von einem Computer verarbeitet werden kann. Kernelemente dieser Semantic Web-Technologien sind Ontologien: formale Darstellungen von Domänwissen, die zum Mo-dellieren von Objekttypen oder Konzepten, deren Eigenschaften und deren Beziehungen verwendet werden können. Diese Ontologien dienen als Datenmodell und Datenstruk-tur für MDO-ArchitekDatenstruk-turen und bieten somit Vorlagen, die für die automatische Forma-lisierung und Integration genutzt werden können. Die Kombination von semantischer Abfrage und einer leichten Form von “Reasoning” über diese Ontologien lieferte einen bedeutenden Nutzen in Bezug auf Leistung, Zuverlässigkeit, Wiederverwendbarkeit und Entwicklungsaufwand in der praktischen Anwendung.
Obwohl die automatische Workflow-Implementierung für ein kommerzielles PIDO-Tool (Noesis Solutions - Optimus) demonstriert wurde, hat sich die Definition eines Prototyps
neutrales Austauschformat für MDO-Probleminformationenergeben aus den entwi-ckelten Ontologien für MDO-Architekturen und ihre formale Übersetzung in Simulations-Workflows. Dies kann als hersteller- und umsetzungsneutrales Format gesehen werden, das alle relevanten Informationen eines Problems nach einer bestimmten MDO-Architektur enthält, ohne die spezifischen Implementierungsdetails eines bestimmten PIDO-Tools. Eine solche neutrale Repräsentation ist nicht nur der Ausgangspunkt, um einen bestimmten MDO-Workflow in ein PIDO-Tool zu übersetzen, sondern auch die von InFoRMA verwendete Datenquelle für die automatische Generierung von XDSMs, die beliebte Erweiterung der klassischen Design Structure Matrix Methode um die Struk-tur eines beliebigen MDO-Problems grafisch darzustellen.
InFoRMA wurde auf mehrere Studien angewendet; von einfachen analytischen Proble-men bis zu (industriellen) aeronautischen ProbleProble-men mit repräsentativer Komplexität. Diese Studien haben folgendes angezeigt:
• die Fähigkeit automatische Formalisierung von MDO-Problemen durchzuführen
für acht gewöhnliche MDO-Architekturen, einschließlich Einzel- und Mehrstufi-ger Architekturen
• die Fähigkeit die Setup-Zeit eines MDO-Workflows von Stunden auf Minuten zu
reduzieren; im Falle eines industriellen Problems wurde für die korrekte Aufstel-lung des Problems nach der MDF-Architektur eine Zeitreduktion von 90% er-reicht.
• Die Möglichkeit MDO-Architekturen zu empfehlen, angesichts des aktuellen
Stan-des der Ontologie und Stan-des Reasoningsystems, zeigte einen begrenzten Nutzen und eine begrenzte Eignung, komplexe MDO-Probleme anzusprechen.
Italian from the Latin “informare”: 1. To form, mould, fashion, give shape to. 2. To delineate, sketch, form an idea. 3. To inform, instruct, educate.
1
I
NTRODUCTION
M
odern-day aircraft that have recently entered service, such as the Boeing 787 andAirbus A350, exhibit high performance levels and a smaller environmental impact than their predecessors. Improvements in various disciplines, such as aerodynamics, airframe structure and propulsion, have allowed these aircraft to reach current, high, performance levels. Not only disciplinary knowledge, but also the understanding by en-gineers of various interactions between disciplines has increased over the years. These become more important with the increasing request for more environmentally friendly aircraft, as the environmental impact is influenced by many disciplines.
The European Commission’s vision on aviation for 2050, Flightpath 2050, sets the
goal to reduce CO2emissions by 75% per passenger kilometer and NOx emissions by
90% relative to the performance of a typical new aircraft in 2000[2]. In addition to these
goals, the Air Transport Action Group has set the target of a 50% reduction in net
avi-ation carbon emissions by 2050 compared to the 2005 levels(1). These goals cannot be
achieved without further improvements of the various basic disciplines and a better un-derstanding of their interactions.
The optimal design of a complex engineering system/product is indeed a compromise between disciplines and it can only be achieved when their interactions are considered and conveniently exploited. Not doing so could result in an aerodynamically optimal airplane that is not structurally efficient and heavy, or has poor passenger comfort and
scarce payload storage. In its extreme, this is illustrated in Figure1.1. Changes in
envi-ronmental regulations and increasingly complex subsystems mean that the considera-tion of discipline interacconsidera-tions will be of paramount importance.
Current aircraft designs have been following a classical iterative engineering design approach. However, this approach relies on the engineers understanding and consid-ering the various discipline interactions during the design process. Such an approach is (1)Anon., Facts & Figures. 2013. URL:http://www.atag.org/facts-and-figures.html[retrieved 21
1
Figure 1.1: Resulting aircraft design if one design or production group is dominant.(1)
not very well suited for novel and more integrated aircraft designs with top-level require-ments, e.g. on environmental impact, that have consequences on multiple disciplines and disciplinary interactions.
Multidisciplinary Design Optimization (MDO) can aid designers to further improve (1)Originally from: L. M. Nicolai & G. E. Carichner, Fundamentals of Aircraft and Airship Design, Volume 1 – Aircraft Design, (2010), American Institute of Aeronautics and Astronautics, Reston, Virginia, USA, ISBN 978-1-60086-751-4; Reprinted with permission from L. M. Nicolai.
tive or unconventional designs, by addressing and exploiting interactions between dis-ciplines. Addressing these interactions is not only necessary to avoid the example of
Figure1.1, but to produce designs that meet the ambitious goals stated before. MDO
provides the structured approach and mathematical formulations to capture and use discipline interactions in the optimization process.
The way of organizing an MDO problem is often referred to as the MDO architecture. This organization can, for example, entail an optimization of a sequence of disciplines or of parallel disciplinary optimizations. These two examples are illustrated
schemati-cally in Figure1.2. An MDO architecture describes the couplings between the various
components of the problem, for example between the disciplines, optimizer(s) and con-straint(s). The architecture defines the structure of the MDO problem, and how it will be solved. It should not be confused with the optimization algorithm, which is the set of (mathematical) steps performed by the optimizer to solve the problem (e.g. to minimize an objective function given certain constraints).
(a) Sequential discipline computations including a convergence loop
(b) Parallel disciplinary optimizations
Figure 1.2: Schematic illustration of two different MDO architectures, one for sequential discipline computa-tions including a convergence loop (a) and one for parallel disciplinary optimizacomputa-tions (b). Both have a system optimizer. The schematic does not include the data exchange between components.
In the schematic drawing of Figure1.2a, a data exchange between different
compo-nents can be envisioned. For example, analysis 1 might provide data for analysis 2. Such a data exchange between analyses is a (interdisciplinary) coupling. Other data exchanges are the values of design variables provided by the optimizer or the computed function and constraint values. The MDO architecture describes the structure of data exchanges and components, the optimization process (i.e. sequence of components) and the data flow between components (i.e. which components exchange which data).
Multiple MDO architectures exist, differing in their formulation and in the way they suit various types of optimization problems. In 2013, Martins and Lambe published an
extensive survey[3], listing various common architectures with a unified notation and
classified based on their problem formulation and decomposition strategy. Additionally, some of their strengths and weaknesses are discussed, which provide some clues to the applicability of the architectures.
To model these architectures and solve the optimization problems, dedicated soft-ware tools can be used or the problem has to be set up through manual programming
1
and interfacing. Examples of these software tools, also referred to as MDO frameworks,are Process Integration and Design Optimization (PIDO) tools such as Optimus(1)andModelCenter(2). MDO frameworks can be seen as managers between the disciplines,
objective(s) and constraints, overseeing the mathematical computations performed to optimize a problem. They are software integration systems in which an MDO architec-ture can be constructed to solve an optimization problem.
1.1.
P
ROBLEMS WITH
MDO
APPLICATION AND RESEARCH
OBJECTIVE
A
lthough MDO has been around for quite some time, it is not yet fully exploited atindustrial level and, so far, it has mainly been demonstrated in literature on
aca-demic problems by expert users (e.g. [4–8]). However, it would be convenient to exploit
MDO in an industrial setting as a commodity method used by design engineers, hence not necessarily academic experts. There are different reasons for the limited application of MDO in industry, whose causes are elaborated below to identify the main challenges that must be overcome to support MDO application.
The limited use and acceptance of MDO in industry was already identified by Agte et
al.[9]. An underlying cause is a limited education in MDO, which, according to Agte et
al., yields a shortage of engineers who understand the concepts and methods of MDO. They note that this absence of education is not limited to the universities, it also occurs
within industry and research organizations[9]. The lack of education in MDO is also
discussed in earlier papers by Giesing and Barthelemy[10] and Belie[11]. On top of that,
the intrinsic complexity makes the selection of a suitable architecture a time-consuming and cumbersome task. Current MDO frameworks still leave the selection and implemen-tation of the most convenient MDO architecture to the user. This is problematic when MDO is to be exploited in industry by people with little experience in the discipline.
Additionally, various literature only provide examples of MDO applications that
fo-cus on the problem definition to use a specific architecture [6,8,12–16], instead of which
architecture to use for a specific problem. Due to the intrinsic complexity of formally modeling MDO problems to integrate all disciplines, variables and interactions in a math-ematically correct fashion, the definition of the problem can be very difficult. Moreover, the definition of industrial MDO problems is generally not flexible and, especially for en-gineering cases, a reformulation might be impossible or undesirable. Hence, a suitable architecture should be selected, instead of reformulating the problem statement to fit a certain architecture (unless a reformulation reduces problem complexity.) Yet, the lack of awareness and understanding make it challenging to select appropriate architectures. Not only the selection of appropriate MDO architectures is influenced by this complex-ity, also the implementation remains challenging. Large and complex problem state-(1)Noesis Solutions - Optimus,http://www.noesissolutions.com/our-products/optimus, accessed on
15 December 2016
(2)Phoenix Integration - ModelCenter,http://www.phoenix-int.com/modelcenter/integrate.php,
1
ments common in industry have to be modeled specifically according to a particulararchitecture. However, the correct formalization of the problem and the associated in-tegration inside an MDO framework remain dependent on the engineer who is mod-eling the problem. With growing problem size and complexity, this job becomes ever more difficult and time consuming, and it has to be repeated for every change in prob-lem definition, for every new optimization probprob-lem or every different architecture. As
Alexandrov and Kodiyalam [17] note, to fully use all advantages of a specific architecture
would require extensive tuning of the problem statement and its implementation. As optimization problems can consist of tens of disciplines and hundreds, or even thou-sands or design variables, manual modeling and tweaking can become a tedious and nerve wrecking endeavor.
Although several languages or grammar for MDO problem formulation have been
de-veloped, such as REMS proposed by Alexandrov & Lewis [18,19] andΨ by Tosserams
[20], no method is available that automatically formalizes an MDO problem into single
level and multilevel MDO architectures, and that integrates the formalized problem in an executable simulation workflow inside an MDO framework. Even frameworks which
provide some support for MDO architectures, such as the implementation inπMDO by
Marriage [21] or the OpenMDAO(1)framework, leave the selection of an appropriate
ar-chitecture and a significant amount of manual, error-prone and time-consuming pro-gramming to implement an MDO architecture to the user.
The challenges identified to cause a high threshold to MDO application can be sum-marized as:
1. Complex, lengthy and error-prone setup process to integrate (even well-) formal-ized MDO problems (according to a specific MDO architecture) into an MDO frame-work to perform the actual optimization.
2. Intrinsic complexity of the process to translate a “real case” multidisciplinary prob-lem into a correct MDO formulation.
3. Lack of awareness and understanding of the many available MDO architectures and their specific suitability to problems of different nature.
Next to these, there are some additional challenges in the execution of MDO studies: 4. Lack of adequately flexible, accurate and robust parametric models to support
MDO using high-fidelity simulations.
5. Limited availability of computational resources to solve complex problems of in-dustrial interest.
The fourth issue can be successfully addressed by knowledge-based parametric CAD (Computer Aided Design) modeling (such as Knowledge Based Engineering (KBE)
appli-cations [22]) and robust preprocessing tools to support high-fidelity analysis. The last
1
issue tends to re-occur from time to time, as the increased availability of computationalresources during design also tends to lead to increasing demands for even more compu-tations. However, the first three issues are not yet addressed.Research question and objectives
The aforementioned, unaddressed challenges limiting the exploitation of MDO as a com-modity method for application by design engineers can be translated to a research ques-tion:
Is it possible to lower the threshold of MDO application to increase its ex-ploitation in an industrial environment?
In combination with the challenges that cause the high threshold to MDO application, this translates to the following objectives to answer the research question:
1. Provide a user with advice on MDO architectures suitable for a particular opti-mization problem.
2. Provide a formal representation of an MDO problem, according to a particular MDO architecture.
3. Automate the implementation of an MDO problem in a simulation workflow.
1.2.
P
OTENTIAL SOLUTION
: I
N
F
O
RMA - I
NTEGRATION
,
F
ORMALIZATION AND
R
ECOMMENDATION OF
MDO
ARCHITECTURES
F
or MDO to be used and make an impact in industry, it must be made accessibleand exploitable by addressing the challenges in MDO application identified in
Sec-tion1.1. This requires support in, not only, the selection (1) or architectures for
engi-neers with little experience in MDO, yet, more importantly, in the formalization (2) and integration (3) of large and complex MDO problems according to specific MDO archi-tectures.
The latter two functionalities are aimed at supporting even experienced users, by removing the required tedious, time consuming, manual implementations. Hence, leav-ing more time for the fine tunleav-ing of the problem definition, the exploration of the design space or performance assessments of designs.
However, as MDO is a powerful method, trusting it in the hands of non-experts may lead to incorrect conclusions in terms of feasibility of results. Therefore, support has to be provided to experienced designers, who understand their domain, to exploit the method to come up with innovative solutions.
Automation has been on the rise in industry over the last decades, with robots taking over more and more repetitive tasks in manufacturing. Also in our daily lives, robots are assisting us with our activities. Think, for example, of vacuum cleaning robots. These robots in essence form a sort of mechanical artificial intelligence, where the robots are controlled automatically, following computer scripts.
RECOMMENDATION OFMDOARCHITECTURES
1
Computational artificial intelligence is also making its way into engineering design,and even our daily lives. For example, automated meshing of finite element models or suggestions for words when typing your text messages. These systems contain a repre-sentation of knowledge, including rules such that computers can reason and make de-cisions. Such systems can assist in decision making and also in designing or integrating products or processes.
Support systems assist their users with processes that require repetitive, non-creative steps. Commonly, these systems are called wizards, automating these steps. However, where the term wizard hints towards the use of magic, advisory systems rely on a proper, formal data model, including rules that allow a computer to reason on existing data, make decisions and infer new information. Any information that is entered into the system is formalized according the same data model, allowing the automated translation of the information to a different format.
Kodiyalam and Sobieszczanski-Sobieski were the first to present a support system as a possible solution in their discussion of MDO framework requirements: “Provide support to easy description and set up of MDO problems using formal, decomposition
based MDO methods [architectures]...”[23] The support that is mentioned in this article
suggests the development of some sort of system that can assist a user to apply MDO.
1.2.1.
I
NFORMA -DESCRIPTION OF THE POTENTIAL SOLUTIONAn innovative methodology and associated prototype system called InFoRMA - Integra-tion, Formalization and Recommendation of MDO architecturesis proposed to support the application of MDO in industry and to lower the threshold of using MDO. InFoRMA should provide support for the application of MDO to exploit its potential for both expe-rienced and inexpeexpe-rienced MDO users, therefore it should:
• Advise(non-expert) users on the selection of MDO architectures, suitable to the problem at hand.
• Formalizea user’s (expert and non-expert) problem according to a selected or suggested architecture’s formal definition in a neutral representation, providing a graphical illustration of the problem and architecture at hand.
• Integratethe formalized problem definition inside a commercial MDO framework as an executable simulation workflow.
Advice in terms of architecture selection means the specification of an MDO prob-lem (i.e. disciplines, variables, objective and constraints) with some additional selection criteria (e.g. consistency of intermediate solutions or need for parallel computations) and the retrieval of a ranked list of suitable MDO architectures.
Currently, advisory functionalities are rarely available in MDO frameworks and if present, the advice is limited to suggestions on the type of algorithm (e.g.
gradient-based or evolutionary) that should be used.[23–27] However, this is insufficient when
disciplinary couplings or variable exchanges are to be considered. Advice in this direc-tion requires support in terms of architecture selecdirec-tion. To the author’s knowledge, there is currently no system that assists with the selection and associated implementation of MDO architectures.
1
Support in formalization of the problem requires a method to automatically formalizethe problem definition according to specific architectures, whose formal definitions are stored inside a knowledge base. These definitions are based on the Extended Design Structure Matrix (XDSM), a unified representation for MDO processes by Lambe andMartins[28]. Formalization guarantees a consistent and easy construction of
optimiza-tion problems for various architectures, whilst adhering to MDO best-practice in terms of formal architecture definitions and applications.
A formal definition is essential to allow support for the integration of a suggested archi-tecture. Formalization requires a data and data model that are presentable in a human-readable (for inspection) and machine-understandable (for automation) way. This should allow a prototype implementation of InFoRMA to take care of the time-consuming man-ual effort of problem definitions and integration in PIDO tools.
1.2.2.
EXPERT SYSTEMS FOR OPTIMIZATION AND RESEARCH CONTEXT
Expert systems attempt to mimic domain experts, by automating tasks and present-ing advice based on knowledge that is contained in the system. Knowledge Based Sys-tems (KBS) are a form of expert sysSys-tems and have been applied to a limited extent in knowledge-based optimum design. The systems reasons upon stored knowledge,
appli-cable to a certain domain [29]. This can be knowledge that is collected from expert users,
but also knowledge gathered from textbooks. Generally speaking, five components can be distinguished in a KBS: a knowledge base, a (graphical) user interface, a work space, a reasoning engine and an explanation system.
• Knowledge Base
The knowledge base can be seen as the long-term memory. It is not problem spe-cific and can consist of many different forms. Typically, a way of structuring the knowledge is added as a lower level to the knowledge base. This can for example be in terms of an ontology, which represents the overall structure.
• (Graphical) User Interface
The user interface allows users to add or remove knowledge. In addition to this, it can be used to query the knowledge that is stored.
• Work space
The work space can be seen as the short-term memory when solving a problem.
• Reasoning Engine
The reasoning engine, or inference engine, is the mechanism that allows the KBS to answer a specific query. It reasons upon the rules or the data structure and returns the data matching the request pattern. It can also deduce non-explicit knowledge in this way. It can alter the work space using the knowledge contained in the knowledge base.
• Explanation system
The explanation system is used to explain how certain information was deduced and which rules were executed to arrive at a certain conclusion.
RECOMMENDATION OFMDOARCHITECTURES
1
Knowledge based optimum design implies the use of knowledge-based systems fordesign optimization. The idea is the application of expert systems to aid and advise the user in setting-up and executing design optimization problems. This could also imply using knowledge from the knowledge base to make design decisions, requiring the im-plementation of artificial intelligence (AI) techniques.
The use of AI can already be found in an article by Arora and Baenziger [30]. Their
study aims to develop an expert (knowledge-based) system to assist the user in design optimization. Next to discussing the requirements, components and architecture of such an expert system and how to integrate knowledge into the system, the paper also presents an implementation of such a system. The implementation has some embedded rules, however the user must manually specify all information and model the problem. The system is able to check the gradient equations that were provided and provides in-formation to improve the starting point, based on some metrics.
The implementation by Arora and Baenziger[30] also addresses the aspect of switching
between algorithms in a hybrid optimization method (e.g. combining genetic and
gra-dient based algorithms). It is also discussed by Carchrae and Beck [31], where a form
of machine learning has been implemented to derive from the behavior of an optimiza-tion problem when to select another algorithm. Reinforcement learning was applied to allocate more run-time to well-performing algorithms.
The use of knowledge in the selection and control of optimization algorithms is also
presented by Balachandran and Gero [32–34]. The goal is to select an algorithm suitable
to the optimization problem. The knowledge is in this application is represented by “if-then”-rules, however, the algorithm selection is relatively trivial.
A knowledge based expert system is also presented by Lee and Kim [35], as a pre- and
post-processor for engineering optimization. The paper describes more advanced re-quirements and features of an expert system than what has actually been implemented. The implemented preprocessor uses past experience from a knowledge base to select suitable input data, such as the bounds on design variables or settings for the imple-mented genetic algorithm. The post-processor aids in the selection of a single, final de-sign point out of a set of Pareto optimal solutions based on metrics derived from experi-ence that has been stored in a knowledge base.
The objectives to answer the research question may be addressed by the implementa-tion of such a knowledge-based expert system. However, knowledge-based technologies have not been applied to multidisciplinary design optimization (MDO) before. These technologies were also not used before to support MDO, allowing both experts and non-experts to apply MDO on their design problems.
Automation is required, formal knowledge on MDO architectures must be used for assistance in the selection of suitable architectures and MDO problems should be rep-resented according to formal definitions (which can be stored in a knowledge base). Hence, also a form of structuring is required for this knowledge base. This research in-vestigates whether and how Semantic Web technologies can be used as part of a solution to lower the threshold of MDO application.
1
should enable a Semantic Webthe existing World Wide Web where meaning (semantics) is added to data, as, for ex-(1)[36,37]. Such a web is envisioned as an extension toample, described by Tim Berners-Lee[38]. Therefore, we do not intend to use an actual
Semantic Web that is extending the World Wide Web, yet, we want to exploit the underly-ing semantic technologies to support MDO application (such as OWL, RDF, SPARQL etc.,
as explained in more detail in Chapter5).
This work contains a synthesis of selection criteria, or guidelines, on the applicability of MDO architectures, collected from various sources of literature and from experience. Additionally, the work is cross-disciplinary as it combines Semantic Web technologies, MDO and simulation workflow management into a methodology to assist users with different levels of experience to implement MDO. This is graphically illustrated in Fig-ure1.3. Knowledge-based (expert) systems Semantic Web technology Artificial Intelligence Multidisciplinary Design Optimization MDO architectures Simulation workflows
InFoRMA
Figure 1.3: Schematic positioning of InFoRMA with respect to artificial intelligence and MDO.
1.2.3.
PERSPECTIVES ON
MDO
PROBLEM FORMUL ATIONSThe XDSM [28] provides an effective way to graphically present the complete structure
of the MDO problem in a human-readable format. However, an extra effort is required to translate a user’s perspective of an MDO problem in both a graphical representation and an executable implementation inside an MDO framework. This involves the definition of a structured knowledge base from which different views can be made. This is illustrated
schematically in Figure1.4.
The XDSM as it is used to present the MDO architectures in [3] does not provide a
clear overview of the actual data exchange between the components of an architecture. Moreover, the execution process that has to be implemented in the framework is not obvious from this representation. Additionally, the data contained in this image is insuf-ficient for an executable workflow to be constructed. Hence, from the same knowledge base the information must be retrieved and formatted in such a way that it can be inte-grated inside a commercial MDO framework. The XDSM serves as part of the structure (1)World Wide Web Consortium (W3C) - Semantic Web;https://www.w3.org/standards/semanticweb/
RECOMMENDATION OFMDOARCHITECTURES
1
XDSM Simula on workflow in MDO framework perspec ve Knowledge Base containing MDO problem User Structured data model Tool + reasoner perspec veFigure 1.4: Schematic representation of MDO problem perspectives. Both the XDSM and simulation workflows can be considered as different perspectives of the same MDO problem. A graphical, human readable version and an executable version.
for the knowledge base and is extended to incorporate simulation workflow data. The data model to structure the knowledge base and support the formalization may be utilized to construct these simulation workflows. This provides integration support, translating a formal definition of an MDO problem according to a certain architecture to a simulation workflow, ready for execution. Hence, a system can take care of all software intensive operations required to integrate the selected architecture for the specific prob-lem in a commercial MDO framework.
InFoRMA is independent of its application domain, i.e. the prototype implementation of InFoRMA does not know whether it is addressing the optimization problem of an air-craft fuselage or a car. Therefore, it can provide the user with different insights into the advantages of changing to a different MDO architecture than one that the user is accus-tomed to. These can for example be differences in optimization time or consistency of intermediate solutions.
1.2.4.
AIM OF THIS THESIS
The aim of this thesis is to increase the exploitation of MDO, by supporting the inte-gration of MDO problems and by lowering the threshold for non-experts to use MDO on their engineering design problems. This requires addressing the complexity, lack of awareness and lack of understanding of MDO architectures. The thesis explains the proposed solution (InFoRMA) and demonstrates it through a prototype implementation and an application to different case studies.
The traditional (academic) way of using different MDO architectures (or strategies to structure an MDO problem) is to redefine the problem to fit a specific architecture. However, the present work takes a more engineering (industrial) approach in identifying which architecture would be suitable to a problem of a specific nature, i.e. taking a dif-ferent perspective to support the application of MDO in industry.
To demonstrate and develop the methodology, a prototype is implemented by means of knowledge-based technologies that allow semantic reasoning and the addition of
