RCE: An Integration Environment for Engineering and Science

Alexander Weinert; Andreas Schreiber; Annika Wohlan; Brigitte Boden; Jan Flink; Kathrin Schaffert; Niklas F\"orst; Robert Mischke

REVIEW 3 major objections 6 minor 22 references

RCE: An Integration Environment for Engineering and Science

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read RCE turns ad-hoc engineering handoffs into automated, distributed multidisciplinary workflows.

desk verdict RCE is a real, clearly described open-source workflow integration tool, but its core usability and efficiency claims are supported only by anecdotes, not by measurements; as a software paper it deserves a serious review, not as a research contribution. read the letter →

arxiv 1908.03461 v2 pith:JZQWUYGI submitted 2019-08-09 cs.SE cs.DC

Brigitte Boden , Jan Flink , Niklas Först , Robert Mischke , Kathrin Schaffert , Alexander Weinert , Annika Wohlan , Andreas Schreiber This is my paper · ORCID

classification cs.SEcs.DC

keywords multidisciplinaryanalysistoolintegrationworkflowexecutioncollaborationdistributedRemoteComponentEnvironmentopen-sourcesoftwareprovenance

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents RCE (Remote Component Environment), an open-source integration environment for multidisciplinary engineering. Its claim is that RCE removes the ad-hoc, error-prone file handoff between specialized tools by letting each engineer publish their tool on their own machine, connecting tools in a visual workflow, and executing the whole graph automatically across networked machines. The reason to care is that design processes that currently run by email, shared drives, or custom scripts become repeatable, recorded, and partly parallel, while each tool stays under the control of the engineer who owns it. This is a software-presentation paper, so the claim is a demonstrated capability rather than a theorem.

What carries the argument

The central machinery is the RCE workflow execution service paired with the tool-integration wrapper. Each tool is wrapped by a definition of input and output data types, optional pre- and post-scripts that convert data between RCE's common formats and tool-specific layouts, and the command to launch the tool. The execution service then runs every tool with no inputs, collects outputs, routes them to connected downstream inputs, and repeats; remote instances communicate through service-interface remote procedure calls, with relay nodes forwarding messages between otherwise disjoint networks. This wrapper-and-dataflow design lets tools running on different operating systems, clusters, or owners' machines appear side by side in the graphical editor and lets the same workflow execute on whatever nodes are available.

What would settle it

The observable test is to start a two-tool RCE workflow whose second tool lives on a remote instance reached only through a relay, then sever the relay link after the first tool finishes; if the workflow controller cannot continue, report an error, or recover, the paper's claim that RCE executes workflows on arbitrary networked nodes over the Internet is not supported for that failure mode.

Watch

Extended reading notes

Core claim

The paper's central claim is that RCE gives engineering teams a single place to formalize, execute, and trace multidisciplinary workflows. The authors would state it as: RCE makes it easy for collaborating engineers to contribute their individual disciplinary tools to a multidisciplinary design or analysis, and it simplifies the subsequent analysis of the workflow's results. Concretely, an engineer integrates a tool once by defining its inputs and outputs, optional pre- and post-scripts, and the command to launch it; RCE then treats that tool as a component that runs on the machine where it was published. Workflows are built by dragging these components into a graph, and execution follows the dataflow: start every tool that has no inputs, collect outputs as tools finish, forward those outputs to the tools that need them, and repeat until no tool produces more data. All inputs and outputs are collected by the workflow controller and stored centrally, giving participants access to the data during and after the run.

Load-bearing premise

The load-bearing premise is that all machines running RCE can reach each other through a working network; the paper says it assumes the networks themselves are connected via the Internet, and if that link drops, the distributed workflow cannot communicate and the paper describes no recovery mechanism.

Editorial extensions

If this is right

Engineering teams can automate the handoff of data between tools that run on different operating systems and different machines, so a workflow no longer depends on one person manually moving files.
Independent branches of a workflow execute in parallel automatically, as illustrated by the low- and high-fidelity aircraft analyses that previously ran sequentially.
All inputs and outputs are stored centrally by the workflow controller, so participants can inspect or analyze results during and after a run, and the provenance of each result is available for later review.
Because tools run on the machine where they were published, proprietary or hardware-bound tools can participate without being copied to other machines, and newly deployed versions are picked up immediately.
The user can designate a server as the workflow controller and shut down their local machine during long-running workflows.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A controlled comparison against manually orchestrated workflows could measure the claimed efficiency gain in wall-clock time and error rate; the paper reports self-assessed increases but not such measurements.
The same wrapper-and-workflow model could be applied outside engineering, for example to scientific data pipelines, since the execution engine treats any command-line tool with defined inputs and outputs identically.
The relay-based network design suggests a natural path to cross-organization collaboration where each partner runs a relay; the paper itself lists encrypted, authenticated transfer of sensitive data as future work, so that scenario depends on a not-yet-delivered component.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You should know two things about this paper. First, it is a competent and unusually honest software description: RCE is an open-source workflow integration environment, the architecture is laid out clearly, and the authors do not hide that impact measurement is hard. Second, the central claim — that RCE makes tool integration and workflow analysis "easy" and "intuitive" — is asserted, not demonstrated. The paper reads like a mature product overview, not like an evaluation.

The strongest part is the presentation. The modular OSGi/Eclipse-based design is sensible, and the features are concrete: pre/post scripts around tools, a graphical editor, a relay system for connecting independent networks, a separate workflow controller, and central data collection. The Zenodo DOI and the open-source availability are real artifacts, and the related work section correctly distinguishes RCE from OpenMDAO, NiFi, and KNIME. On its own terms, the system description is internally consistent and plausible.

Where it gets soft is Section 4. The impact claims come down to "users have lauded features" and "users report increased productivity," with no error rates, completion times, or baseline comparisons. The stress-test note is right that the Section 3 network connectivity assumption is minor — any distributed system assumes reachability. The more serious gap is that "easy" and "simplifies" are never operationalized. Because RCE is open source with a DOI, this gap is empirically checkable; the authors could have shipped a tutorial workflow or a repeatable benchmark. Their own admission that impact is "hard to measure" is fair, but it does not excuse the absence of any attempt.

The citation pattern is acceptable. The self-citations point to prior RCE publications and project reports, not to fabricated evidence. As a new result, there is nothing here — no equations, no measurements — but that is normal for a software description paper. The audience is clear: engineers who want to know whether RCE fits their integration needs, and researchers studying MDO tooling.

My recommendation: if the venue has a software or tools track, send it to peer review with a request for concrete evidence — a link to a reproducible demo, a tutorial workflow with expected outputs, or at least a structured qualitative evaluation. For a general research track, a desk reject would also be defensible, because the novelty bar is low. But the paper is not a waste of referee time; it just needs to be held to a software-report standard.

Referee Report

3 major / 6 minor

Summary. This paper describes RCE (Remote Component Environment), an open-source workflow integration environment developed at DLR. It reports the system's user-facing features: wizard-based tool integration, a graphical workflow editor, distributed execution of workflows over networked RCE instances, central collection and storage of all workflow data, and support for active development versions of tools. It outlines the architecture (Java, Eclipse RCP, OSGi services, JMS/SSH communication) and presents a fictitious aviation wing-design example. It then summarizes several DLR projects (FrEACs, Digital-X, PEGASUS, TRIAD, CLAVA) in which RCE was used, with users reported to be more productive. The paper concludes with future work on workflow modularization, cloud support, and secure communication.

Significance. RCE appears to be a real, open-source system with a sensible modular architecture; the OSGi service design, central provenance collection, and support for heterogeneous runtime environments are credible strengths. The paper ships a Zenodo DOI for the software, which makes claims checkable. However, the paper's headline claims that RCE 'makes it easy' and 'greatly increased efficiency' are not supported by any systematic evaluation; the only evidence is anecdotal and largely self-referential project reports. The usefulness of the paper as a research artifact therefore depends on either adding evaluative evidence or substantially reframing the claims as an experience/software report.

major comments (3)

[Section 1 and Section 4] The central usability and efficiency claim is asserted without measured evidence. The abstract and Section 1 state that RCE 'makes it easy' and that users 'greatly increased their efficiency'; Section 4 repeats these claims and Section 4.2 says performance 'improved markedly' [9]. No user study, task completion times, error rates, speedup measurements, or comparison against a baseline (e.g., ad-hoc file transfer or a commercial tool) are provided. Section 4 itself concedes that impact is hard to measure. Because RCE is open-source with a Zenodo DOI, an evaluation is feasible; without it, the main claim cannot be verified by the reader.
[Section 4] The supporting evidence for impact is largely self-referential. The claim that 'numerous users have lauded particular features' is backed by reference [5], the authors' own AIAA paper, and the project successes are described in papers by the same development and user community ([9], [10], [14], [19], [22]). These are not independent verification. I would ask the authors to either supply independently collected user evidence, quantitative workflow metrics, or clearly label Section 4 as an experience report rather than an evaluation.
[Section 2.1] The description of workflow execution is too underspecified to support the reproducibility of the central execution claim. The text says that execution continues 'until no tool has produced any further output data,' but the paper also advertises optimization loops (Dakota integration) and iterative design workflows; a dataflow engine with this termination rule does not explain how loop iterations or convergence criteria are handled, nor how concurrent data dependencies are scheduled. Please specify the execution semantics (e.g., dataflow firing rules, loop handling, termination conditions) or provide a traceable example with a small workflow.

minor comments (6)

[Section 2.2] 'JavaX JMS' is not a standard name; use 'Java Message Service (JMS)' or 'javax.jms.'
[Section 4] 'features of RCE that have of great use in their projects' should read 'that have been of great use.'
[Section 1 (Related Work)] The statement that 'no other software shares the concept and aim of RCE' is too strong; at least Kepler, Taverna, Pegasus, and Nextflow provide distributed scientific workflow management and should be discussed or explicitly differentiated.
[Reference [14]] 'Bhnke' should be 'Böhnke' (and the umlaut should be preserved in the citation).
[Manuscript availability] The manuscript would be easier to verify if the software availability were stated in the text (e.g., a URL to the repository or release) rather than only through reference [4].
[Section 4.2] 'The performance of these individual steps improved markedly' would benefit from stating the measured metric (wall-clock time, turnaround time, number of manual interventions) and the baseline.

Circularity Check

1 steps flagged · score 2.0 of 10

No structural circularity; the only self-referential element is a minor self-citation in the impact section, and the central software claims are independently checkable.

other [Section 4 (Impact), first paragraph; supported by reference [5]]
"However, numerous users have lauded particular features of RCE that have of great use in their projects, such as the capability to create repeatable and reusable workflows, or the ability to seamlessly perform simulations on a distributed network [5]."

The citation attached to this user-praise claim is reference [5], a prior paper by the same DLR author group (Boden, Flink, Mischke, Schaffert, Weinert, Wohlan, Schreiber, et al.), not an independent user survey or benchmark. The impact evidence therefore reduces to a self-citation rather than receiving external support. This is a minor self-referential loop only: the main technical content of the paper is self-contained, and the existence and core functionality of RCE can be independently verified through the open-source release identified by the Zenodo DOI.

full rationale

This paper is a software description rather than a derivation; it contains no equations, fitted parameters, or quantitative predictions whose values could reduce to their own inputs. The technical sections (Sections 2 and 3) describe RCE's functionality and architecture in a self-contained way, and the central claim that the software exists and enables graphical, distributed workflow execution is independently checkable through the open-source code and published DOI. The only self-citation carrying evidential weight appears in Section 4, where the claim that users laud RCE's features is backed by reference [5], the authors' own prior paper. This makes the impact discussion partly self-referential, but the paper itself admits that impact is 'hard to measure' and this discussion is not load-bearing for the main technical claims. The network-connectivity assumption in Section 3 is an explicit stated precondition rather than a concealed input. Overall, no meaningful derivation chain is circular; the minor self-citation warrants a low score rather than a finding of substantive circularity.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities. It relies on an environmental assumption about network connectivity and on the general assumption that disciplinary tools can be wrapped with input/output definitions.

assumptions (2)

domain assumption The networks connecting RCE instances are connected via the Internet; otherwise no communication is possible.
Stated in Section 3, this is required for distributed workflow execution.
domain assumption Each disciplinary tool can be integrated into RCE by defining inputs, outputs, and pre/post-scripts.
The paper assumes any tool can be wrapped this way, which may fail for tools with complex interactive interfaces or specific runtime dependencies.

how reviews work

0 comments

Cite this review

Pith. "Pith review of RCE: An Integration Environment for Engineering and Science." pith.science (2026). https://pith.science/paper/JZQWUYGI

@misc{pith2026190803461,
  author       = {Pith},
  title        = {Pith review of: RCE: An Integration Environment for Engineering and Science},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JZQWUYGI}},
  note         = {Machine review of arXiv:1908.03461}
}

read the original abstract

We present RCE (Remote Component Environment), an open-source framework developed primarily at DLR (German Aerospace Center) that enables its users to construct and execute multidisciplinary engineering workflows comprising multiple disciplinary tools. To this end, RCE supplies users with an easy-to-use graphical interface that allows for the intuitive integration of disciplinary tools. Users can execute the individual tools on arbitrary nodes present in the network and all data accrued during the execution of the workflow are collected and stored centrally. Hence, RCE makes it easy for collaborating engineers to contribute their individual disciplinary tools to a multidisciplinary design or analysis, and simplifies the subsequent analysis of the workflow's results.

Figures

Figures reproduced from arXiv: 1908.03461 by the authors.

**Figure 1.** Process for designing and evaluating a wing shape. using Matlab [13] on a compute cluster. Finally, the aerodynamic evaluation may be performed using a simulation implemented in Fortran [3] using a GPU cluster while the estimate of production costs may be implemented in Java [21]. There are several obstacles in executing such a multidisciplinary design process. Not only do the participants from different disciplines… view at source ↗

**Figure 2.** A conceptual view of the integration of a tool into RCE. In addition to the user-integrated tools, RCE provides a number of predefined tools which supply basic and often-needed functionalities such as controlling the flow of data through the workflow, reading and extracting data from XML files, executing user-supplied Python scripts, as well as a number of tools that provide mathematical and statistical methods to e… view at source ↗

**Figure 3.** A workflow in RCE. The fontsize of the labels has been increased for the sake of readability. After constructing the workflow, the user can start its execution. As a first step, RCE triggers the execution of all tools without inputs. Once a tool has terminated, RCE collects its outputs as defined by its integration and computed by its post-script, and passes them on to the tools whose inputs are connected to the out… view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: A top-level view of the services implemented in RCE. As of version 10.0, RCE has more than 230 service interfaces. We only present an overview of its major functional groups in [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

**Figure 5.** Figure 5: A typical setup of RCE instances and the communication between them. For communication between different instances, we also use service interfaces to define remote procedure calls (RPCs), which help us in achieving the final requirement above. On a source code level, …

**Figure 6.** Figure 6: Excerpt of the services involved in the execution of a workflow via the GUI. namely over the construction and execution of a workflow via the GUI. We illustrate the services involved and the communcation between them in [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

**Figure 7.** Figure 7: A network setup of the machines taking part in the process shown in [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 21 canonical work pages

[9]

In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference

Goertz, S., Ilic, C., Jepsen, J., Leitner, M., Schulze, M., Schuster, A., Scherer, J., Becker, R., Zur, S., Petsch, M.: Multi-Level MDO of a Long-Range Transport Aircraft Using a Distributed Analysis Frame- work. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference. AIAA (2017). https://doi.org/10.2514/6.2017-4326

work page doi:10.2514/6.2017-4326 2017
[5]

In: AIAA Aviation 2019 Forum

Boden, B., Flink, J., Mischke, R., Schaﬀert, K., Weinert, A., Wohlan, A., Ilic, C., Wunderlich, T., Liersch, C.M., Goertz, S., Ciampa, P.D., Moerland, E.: Distributed Multidisciplinary Optimization and Collaborative Process Development Using RCE. In: AIAA Aviation 2019 Forum. American Institute of Aeronautics and Astronautics (June 2019). https://doi.org/...

work page doi:10.2514/6.2019-2989 2019
[10]

In: ICAS 2016 (2016), available at https://www.icas.org/ICAS_ARCHIVE/ICAS2016/data/papers/ 2016_0345_paper.pdf

G¨ ortz, S., Ilic, C., Abu-Zurayk, M., Liepelt, R., Jepsen, J., F¨ uhrer, T., Becker, R.G., Scherer, J., Kier, T., Siggel, M.: Collaborative Multi-Level MDO Process Development and Application to Long-Range Transport Aircraft. In: ICAS 2016 (2016), available at https://www.icas.org/ICAS_ARCHIVE/ICAS2016/data/papers/ 2016_0345_paper.pdf

work page 2016
[14]

In: 17th AIAA Aviation Technology, Integration, and Operations Conference

Moerland, E., Pfeiﬀer, T., Bhnke, D., Jepsen, J., Freund, S., Liersch, C.M., Chiozzotto, G.P., Klein, C., Scherer, J., Hasan, Y.J., Flink, J.: On the Design of a Strut-Braced Wing Conﬁguration in a Collaborative Design Environment. In: 17th AIAA Aviation Technology, Integration, and Operations Conference. American Institute of Aeronautics and Astronautics...

work page doi:10.2514/6.2017-4397 2017
[19]

Journal of Engineering for Gas Turbines and Power 141(1) (September 2018)

Reitenbach, S., Krumme, A., Behrendt, T., Schn¨ os, M., Schmidt, T., H¨ onig, S., Mischke, R., Moerland, E.: Design and Application of a Multi-Disciplinary Pre-Design Process for Novel Engine Concepts. Journal of Engineering for Gas Turbines and Power 141(1) (September 2018). https://doi.org/10.1115/1.4040750

work page doi:10.1115/1.4040750 2018
[22]

Aerospace 6(2) (2019)

Weiand, P., Buchwald, M., Schwinn, D.: Process Development for Integrated and Distributed Rotorcraft De- sign. Aerospace 6(2) (2019). https://doi.org/10.3390/aerospace6020023, http://www.mdpi.com/2226-4310/ 6/2/23 11

work page doi:10.3390/aerospace6020023 2019
[1]

Sandia Technical Report SAND2014-4633 (Jul 2014), available at https://dakota.sandia.gov/content/manuals

Adams, B., Bauman, L., Bohnhoﬀ, W., Dalbey, K., Ebeida, M., Eddy, J., Eldred, M., Hough, P., Hu, K., Jakeman, J., Stephens, J., Swiler, L., Vigil, D., , Wildey, T.: Dakota, A Multilevel Parallel Object- Oriented Framework for Design Optimization, Parameter Estimation, Uncertainty Quantiﬁcation, and Sen- sitivity Analysis: Version 6.0 Users Manual. Sandia ...

work page 2014
[2]

Apache Software Foundation, Cloudera, Hortonworks: Apache Niﬁ, available at https://nifi.apache.org/

work page

Show all 22 references

[3]

Backus, J., IBM, ISO: The Fortran Programming Language
[4]

https://doi.org/10.5281/zenodo.3691675 10

Boden, B., Flink, J., Mischke, R., Schaﬀert, K., Weinert, A., Wohlan, A., Schreiber, A.: RCE (November 2019). https://doi.org/10.5281/zenodo.3691675 10

2019 doi
[6]

Eclipse Foundation: Eclipse Equinox, available at https://www.eclipse.org/equinox/
[7]

Eclipse Foundation: Rich Client Platform, https://wiki.eclipse.org/Rich_Client_Platform
[8]

In: 69th International Astronautical Congress (IAC) (October 2018), available athttps://elib.dlr.de/122158/

Fischer, P.M., Deshmukh, M., Koch, A.D., Mischke, R., Gomez, A.M., Schreiber, A., Gerndt, A.: Enabling a Conceptual Data Model and Workﬂow Integration Environment for Concurrent Launch Vehicle Analysis. In: 69th International Astronautical Congress (IAC) (October 2018), availa...

2018
[11]

Structural and Multidisciplinary Optimization 59(4), 1075–1104 (April 2019)

Gray, J.S., Hwang, J.T., Martins, J.R.R.A., Moore, K.T., Naylor, B.A.: OpenMDAO: An open-source frame- work for multidisciplinary design, analysis, and optimization. Structural and Multidisciplinary Optimization 59(4), 1075–1104 (April 2019). https://doi.org/10.1007/s00158-019-02211-z

2019 doi
[12]

KNIME AG: KNIME, https://www.knime.com/
[13]

MathWorks, Inc.: MATLAB, https://www.mathworks.com/products/matlab.html
[15]

OSGi Alliance: OSGi Compendium Release 7 - Declarative Services Speciﬁcation, https://osgi.org/ specification/osgi.cmpn/7.0.0/service.component.html
[16]

(ed.): A Holistic Approach to Ship Design

Papanikolaou, A. (ed.): A Holistic Approach to Ship Design. Springer International Publishing (2019). https://doi.org/10.1007/978-3-030-02810-7

2019 doi
[17]

Phoenix Integration: Model Center, https://www.phoenix-int.com
[18]

Python Contributors: The Python Programming Language, available at https://www.python.org
[20]

Internationales Verkehrswesen (2), 49–53 (2019)

Seum, S., Ehrenberger, S., Kuhnimhof, T., Winkler, C.: Verkehr und seine Umweltwirkungen. Internationales Verkehrswesen (2), 49–53 (2019)

2019
[21]

Sun Microsystems: The Java Programming Language, https://www.oracle.com/java

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [9]

In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference

Goertz, S., Ilic, C., Jepsen, J., Leitner, M., Schulze, M., Schuster, A., Scherer, J., Becker, R., Zur, S., Petsch, M.: Multi-Level MDO of a Long-Range Transport Aircraft Using a Distributed Analysis Frame- work. In: 18th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference. AIAA (2017). https://doi.org/10.2514/6.2017-4326

work page doi:10.2514/6.2017-4326 2017

[2] [5]

In: AIAA Aviation 2019 Forum

Boden, B., Flink, J., Mischke, R., Schaﬀert, K., Weinert, A., Wohlan, A., Ilic, C., Wunderlich, T., Liersch, C.M., Goertz, S., Ciampa, P.D., Moerland, E.: Distributed Multidisciplinary Optimization and Collaborative Process Development Using RCE. In: AIAA Aviation 2019 Forum. American Institute of Aeronautics and Astronautics (June 2019). https://doi.org/...

work page doi:10.2514/6.2019-2989 2019

[3] [10]

In: ICAS 2016 (2016), available at https://www.icas.org/ICAS_ARCHIVE/ICAS2016/data/papers/ 2016_0345_paper.pdf

G¨ ortz, S., Ilic, C., Abu-Zurayk, M., Liepelt, R., Jepsen, J., F¨ uhrer, T., Becker, R.G., Scherer, J., Kier, T., Siggel, M.: Collaborative Multi-Level MDO Process Development and Application to Long-Range Transport Aircraft. In: ICAS 2016 (2016), available at https://www.icas.org/ICAS_ARCHIVE/ICAS2016/data/papers/ 2016_0345_paper.pdf

work page 2016

[4] [14]

In: 17th AIAA Aviation Technology, Integration, and Operations Conference

Moerland, E., Pfeiﬀer, T., Bhnke, D., Jepsen, J., Freund, S., Liersch, C.M., Chiozzotto, G.P., Klein, C., Scherer, J., Hasan, Y.J., Flink, J.: On the Design of a Strut-Braced Wing Conﬁguration in a Collaborative Design Environment. In: 17th AIAA Aviation Technology, Integration, and Operations Conference. American Institute of Aeronautics and Astronautics...

work page doi:10.2514/6.2017-4397 2017

[5] [19]

Journal of Engineering for Gas Turbines and Power 141(1) (September 2018)

Reitenbach, S., Krumme, A., Behrendt, T., Schn¨ os, M., Schmidt, T., H¨ onig, S., Mischke, R., Moerland, E.: Design and Application of a Multi-Disciplinary Pre-Design Process for Novel Engine Concepts. Journal of Engineering for Gas Turbines and Power 141(1) (September 2018). https://doi.org/10.1115/1.4040750

work page doi:10.1115/1.4040750 2018

[6] [22]

Aerospace 6(2) (2019)

Weiand, P., Buchwald, M., Schwinn, D.: Process Development for Integrated and Distributed Rotorcraft De- sign. Aerospace 6(2) (2019). https://doi.org/10.3390/aerospace6020023, http://www.mdpi.com/2226-4310/ 6/2/23 11

work page doi:10.3390/aerospace6020023 2019

[7] [1]

Sandia Technical Report SAND2014-4633 (Jul 2014), available at https://dakota.sandia.gov/content/manuals

Adams, B., Bauman, L., Bohnhoﬀ, W., Dalbey, K., Ebeida, M., Eddy, J., Eldred, M., Hough, P., Hu, K., Jakeman, J., Stephens, J., Swiler, L., Vigil, D., , Wildey, T.: Dakota, A Multilevel Parallel Object- Oriented Framework for Design Optimization, Parameter Estimation, Uncertainty Quantiﬁcation, and Sen- sitivity Analysis: Version 6.0 Users Manual. Sandia ...

work page 2014

[8] [2]

Apache Software Foundation, Cloudera, Hortonworks: Apache Niﬁ, available at https://nifi.apache.org/

work page