Planetary research is often user-based and requires considerable skill, time, and effort. Unfortunately, self-defined boundary conditions, definitions, and rules are often not documented or not easy to comprehend due to the complexity of research. This makes a comparison to other studies, or an extension of the already existing research, complicated. Comparisons are often distorted, because results rely on different, not well defined, or even unknown boundary conditions. The purpose of this research is to develop a standardized analysis method for planetary surfaces, which is adaptable to several research topics. The method provides a consistent quality of results. This also includes achieving reliable and comparable results and reducing the time and effort of conducting such studies. A standardized analysis method is provided by automated analysis tools that focus on statistical parameters. Specific key parameters and boundary conditions are defined for the tool application. The analysis relies on a database in which all key parameters are stored. These databases can be easily updated and adapted to various research questions. This increases the flexibility, reproducibility, and comparability of the research. However, the quality of the database and reliability of definitions directly influence the results. To ensure a high quality of results, the rules and definitions need to be well defined and based on previously conducted case studies. The tools then produce parameters, which are obtained by defined geostatistical techniques (measurements, calculations, classifications). The idea of an automated statistical analysis is tested to proof benefits but also potential problems of this method. In this study, I adapt automated tools for floor-fractured craters (FFCs) on Mars. These impact craters show a variety of surface features, occurring in different Martian environments, and having different fracturing origins. They provide a complex morphological and geological field of application. 433 FFCs are classified by the analysis tools due to their fracturing process. Spatial data, environmental context, and crater interior data are analyzed to distinguish between the processes involved in floor fracturing. Related geologic processes, such as glacial and fluvial activity, are too similar to be separately classified by the automated tools. Glacial and fluvial fracturing processes are merged together for the classification. The automated tools provide probability values for each origin model. To guarantee the quality and reliability of the results, classification tools need to achieve an origin probability above 50 %. This analysis method shows that 15 % of the FFCs are fractured by intrusive volcanism, 20 % by tectonic activity, and 43 % by water & ice related processes. In total, 75 % of the FFCs are classified to an origin type. This can be explained by a combination of origin models, superposition or erosion of key parameters, or an unknown fracturing model. Those features have to be manually analyzed in detail. Another possibility would be the improvement of key parameters and rules for the classification. This research shows that it is possible to conduct an automated statistical analysis of morphologic and geologic features based on analysis tools. Analysis tools provide additional information to the user and are therefore considered assistance systems. / Planetenforschung umfasst oft zeitintensive Projekte, bei denen Expertise und Erfahrung eine wesentliche Rolle spielen. Auf Grund äusserst komplexer und sich selten wiederholender Forschungsfragen sind Annahmen, Definitionen und Regeln zur Lösung dieser Fragen nicht leicht nachvollziehbar oder aber nicht eindeutig dokumentiert. Ein Vergleich der Ergebnisse unterschiedlicher Forscher zum selben Thema oder eine Erweiterung der Forschungsfrage macht dies somit nur schwer möglich. Vergleiche liefern oftmals verzerrte Ergebnisse, da die Ausgangslage und Randbedingungen unterschiedlich definiert worden sind. Das Ziel dieser Arbeit ist es eine Standardmethode zur Oberflächenanalyse zu entwickeln, die auf zahlreiche Untersuchungsfragen angewandt werden kann. Eine gleichbleibende Qualität der Ergebnisse muss durch diese Methode gewährleistet sein. Ein weiteres Ziel ist es, dass diese Methode ohne Vorwissen und Expertise angewandt werden kann und die Ergebnisse in kurzer Zeit vorliegen. Ausserdem müssen die Ergebnisse vergleichbar und nachvollziehbar sein. Automatisch operierende Analysewerkzeuge können die zahlreichen Anforderungen erfüllen und als Standardmethode dienen. Statistische Ergebnisse werden durch diese Methode erzielt. Die Werkzeuge basieren auf vordefinierten, geowissenschaftlichen Techniken und umfassen Messungen, Berechnungen und Klassifikationen der zu untersuchenden Oberflächenstrukturen. Für die Anwendung dieser Werkzeuge müssen Schlüsselstrukturen und Randbedingungen definiert werden. Des Weiteren benötigen die Werkzeuge eine Datenbank, in der alle Oberflächenstrukturen, aber auch Informationen zu den Randbedingungen gespeichert sind. Es ist mit geringem Aufwand möglich, Datenbanken zu aktualisieren und sie auf verschiedenste Fragestellungen zu adaptieren. Diese Tatsache steigert die Flexibilität, Reproduzierbarkeit und auch Vergleichbarkeit der Untersuchung. Die vordefinierten Randbedingungen und die Qualität der Datenbank haben jedoch auch direkten Einfluss auf die Qualität der Ergebnisse. Um eine gleichbleibend hohe Qualität der Untersuchung zu gewährleisten muss sichergestellt werden, dass alle vordefinierten Bedingungen eindeutig sind und auf vorheriger Forschung basieren. Die automatisch operierenden Analysewerkzeuge müssen als mögliche Standardmethode getestet werden. Hierbei geht es darum Vorteile, aber auch Nachteile zu identifizieren und zu bewerten. In dieser Arbeit werden die Analysewerkzeuge auf einen bestimmten Einschlagskratertyp auf dem Mars angewandt. Krater mit zerbrochenen Kraterböden (Floor-Fractured Craters) sind in verschiedensten Regionen auf dem Mars zu finden, sie zeigen zahlreiche Oberflächenstrukturen und wurden durch unterschiedliche Prozesse geformt. All diese Fakten machen diesen Kratertyp zu einem interessanten und im geologischen und morphologischen Sinne sehr komplexen Anwendungsgebiet. 433 Krater sind durch die Werkzeuge analysiert und je nach Entstehungsprozess klassifiziert worden. Für diese Analyse sind Position der Krater, Art des Umfeldes und Strukturen im Kraterinneren ausschlaggebend. Die kombinierten Informationen geben somit Auskunft über die Prozesse, welche zum Zerbrechen des Kraterbodens geführt haben. Die entwickelten Analysewerkzeuge können geologische Prozesse, die sehr ähnlich zueinander sind, von einander abhängig sind und zusätzlich auch dieselben Oberflächenstrukturen formen, nicht eindeutig unterscheiden. Aus diesem Grund sind fluviale und glaziale Entstehungsprozesse für den untersuchten Kratertyp zusammengefasst. Die Analysewerkzeuge liefern Wahrscheinlichkeitswerte für drei mögliche Entstehungsarten. Um die Qualität der Ergebnisse zu verbessern muss eine Wahrscheinlichkeit über 50 % erreicht werden. Die Werkzeuge zeigen, dass 15 % der Krater durch Vulkanismus, 20 % durch Tektonik und 43 % durch Wasser- und Eis-bedingte Prozesse gebildet wurden. Insgesamt kann für 75 % des untersuchten Kratertyps ein potentieller Entstehungsprozess zugeordnet werden. Für 25 % der Krater ist eine Klassifizierung nicht möglich. Dies kann durch eine Kombination von geologischen Prozessen, einer Überprägung von wichtigen Schlüsselstrukturen, oder eines bisher nicht berücksichtigten Prozesses erklärt werden. Zusammenfassend ist zu sagen, dass es möglich ist planetare Oberflächenstrukturen quantitativ durch automatisch operierende Analysewerkzeuge zu erfassen und hinsichtlich einer definierten Fragestellung zu klassifizieren. Zusätzliche Informationen können durch die entwickelten Werkzeuge erhalten werden, daher sind sie als Assistenzsystem zu betrachten.

Software has never been as important as today – and its impact on life, work and society is growing at an impressive rate. We are in the flow of a software-induced transformation of nearly all aspects of our way of life and work. The dependence on software has become almost total. Malfunctions and unavailability may threaten vital areas of our society, life and work at any time. The two massive challenges of software are one hand the complexity of the software and on the other hand the disruptive environment. Complexity of the software is a result of the size, the continuously growing functionality, the more complicated technology and the growing networking. The unfortunate consequence is that complexity leads to many problems in design, development, evolution and operation of software-systems, especially of large software-systems. All software-systems live in an environment. Many of today’s environments can be disruptive and cause severe problems for the systems and their users. Examples of disruptions are attacks, failures of partner systems or networks, faults in communications or malicious activities. Traditionally, both growing complexity and disruptions from the environment have been tackled by better and better software engineering. The development and operating processes are constantly being improved and more powerful engineering tools are introduced. For defending against disruptions, predictive methods – such as risk analysis or fault trees – are used. All this techniques are based on the ingenuity, experience and skills of the engineers! However, the growing complexity and the increasing intensity of possible disruptions from the environment make it more and more questionable, if people are really able to successfully cope with this raising challenge in the future. Already, serious research suggests that this is not the case anymore and that we need assistance from the software-systems themselves! Here enters “autonomic computing” – A promising branch of software science which enables software-systems with self-configuring, self-healing, self-optimization and self-protection capabilities. Autonomic computing systems are able to re-organize, optimize, defend and adapt themselves with no real-time human intervention. Autonomic computing relies on many branches of science – especially computer science, artificial intelligence, control theory, machine learning, multi-agent systems and more. Autonomic computing is an active research field which currently transfers many of its results into software engineering and many applications. This Hauptseminar offered the opportunity to learn about the fascinating technology “autonomic computing” and to do some personal research guided by a professor and assisted by the seminar peers.

Ein großer Bereich der Bioinformatik ist die automatische Annotation von Genen. Hier gibt es einige Systeme, die speziell für die Annotation in mitochondrialen Genomen ausgelegt sind. So sind MOSAS1[16], MITOS2[6] und DOGMA3[20] zu erwähnen. Alle können mehr oder weniger automatisch die Proteine, tRNAs und rRNAs annotieren. Keins von ihnen kann aber die Kontrollregionen bzw. den D- Loop vorhersagen. Diese Arbeit beschäftigt sich mit dieser Lücke und versucht Möglichkeiten zu finden, die eine Automatisierung der Annotation des D-Loop zu erlauben. Als Grundlage für die verschiedenen Annäherungen und die Bewertung der Ergebnisse werden die Annotationen des D-Loops in der NCBI RefSeq 464[13] benutzt. Hier wird eine besondere Aufmerksamkeit auf die Säugetiere gelegt. Dies ist damit begründet, dass es sich dabei um eine übersichtliche Gruppe mit vielen annotierten D-Loop Regionen handelt. So werden mit den Programmen Fragrep [12] und Blast [1] versucht einzelne Merkmale aus dem D-Loop zu annotieren. Diese werden dann zu einer gesamt Annotation des D-Loops im D-Loop-Finder zusammengesetzt.

Zur Sanierung von Heizflächen in Kraftwerks- und Müllverbrennungsanlagen ist das Auftragschweißen eine bewährte Methode. Dazu wurde von der DH Schweißtechnologie & Service Hohenthurm GmbH & Co. KG in Zusammenarbeit mit der Technischen Universität Chemnitz eine neue vollmechanisierte Schweißanlage entwickelt. Durch das Anlagenkonzept ergeben sich neue technologische Möglichkeiten sowie Qualitätsverbesserungen der aufgetragenen Schichten und eine Reduzierung der Fertigungszeit. / Weld overlay is a proven method for refurbishing boiler tubes in power plants and sewage sludge burning plants. DH Schweisstechnologie & Service Hohenthurm GmbH & Co. KG in cooperation with the University of Technology Chemnitz developed a new automatic welding with different welding alloys, different thicknesses and coating structures under any adjusted to the operating condition of the boiler.

Die Herstellung großer, dickwandiger Schweißkonstruktionen ist durch einen hohen fertigungstechnischen Aufwand gekennzeichnet. Dieser erhöht sich mit zunehmender Bauteilgröße in überproportionalem Maße. Mit dem Beginn der Fertigung von Gründungsstrukturen für Offshore-Windenergieanlagen, stellt sich die Frage nach der Automatisierung schweißtechnischer Prozesse neu. Im Rahmen einer Machbarkeitsstudie wurde ein schienengeführtes traktorähnliches System entwickelt. Der folgende Pro Engineer Anwendervortrag umfasst das Erstellen dreidimensional geformter Schienensegmente. Weiterhin wird das Gesamtsystem der schweißtechnischen Automatisierung, bestehend aus Schweißtraktor und Schiene, mit Hilfe von Gelenkverbindungen in Pro Engineer zu einer zwnagsläufigen räumlichen Kinematik verbunden. Außerdem wird die Fahrt des Schweißtraktors entlang der Schweißfugenkontur an Hand einer Animation gezeigt, welche mit Pro Engineer DAO (Design Animation Option) erstellt wurde.

Software has never been as important as today – and its impact on life, work and society is growing at an impressive rate. We are in the flow of a software-induced transformation of nearly all aspects of our way of life and work. The dependence on software has become almost total. Malfunctions and unavailability may threaten vital areas of our society, life and work at any time. The two massive challenges of software are one hand the complexity of the software and on the other hand the disruptive environment. Complexity of the software is a result of the size, the continuously growing functionality, the more complicated technology and the growing networking. The unfortunate consequence is that complexity leads to many problems in design, development, evolution and operation of software-systems, especially of large software-systems. All software-systems live in an environment. Many of today’s environments can be disruptive and cause severe problems for the systems and their users. Examples of disruptions are attacks, failures of partner systems or networks, faults in communications or malicious activities. Traditionally, both growing complexity and disruptions from the environment have been tackled by better and better software engineering. The development and operating processes are constantly being improved and more powerful engineering tools are introduced. For defending against disruptions, predictive methods – such as risk analysis or fault trees – are used. All this techniques are based on the ingenuity, experience and skills of the engineers! However, the growing complexity and the increasing intensity of possible disruptions from the environment make it more and more questionable, if people are really able to successfully cope with this raising challenge in the future. Already, serious research suggests that this is not the case anymore and that we need assistance from the software-systems themselves! Here enters “autonomic computing” – A promising branch of software science which enables software-systems with self-configuring, self-healing, self-optimization and self-protection capabilities. Autonomic computing systems are able to re-organize, optimize, defend and adapt themselves with no real-time human intervention. Autonomic computing relies on many branches of science – especially computer science, artificial intelligence, control theory, machine learning, multi-agent systems and more. Autonomic computing is an active research field which currently transfers many of its results into software engineering and many applications. This Hauptseminar offered the opportunity to learn about the fascinating technology “autonomic computing” and to do some personal research guided by a professor and assisted by the seminar peers.:Introduction 5 1 What Knowledge Does a Taxi Need? – Overview of Rule Based, Model Based and Reinforcement Learning Systems for Autonomic Computing (Anja Reusch) 11 2 Chancen und Risiken von Virtual Assistent Systemen (Felix Hanspach) 23 3 Evolution einer Microservice Architektur zu Autonomic Computing (Ilja Bauer) 37 4 Mögliche Einflüsse von autonomen Informationsdiensten auf ihre Nutzer (Jan Engelmohr) 49 5 The Benefits of Resolving the Trust Issues between Autonomic Computing Systems and their Users (Marc Kandler) 61

No description available.

No description available.

Der Bau- und Liegenschaftsbetrieb Nordrhein-Westfalen (BLB NRW) gehört zu den großen Auftraggebern von Bauleistungen am Markt und ist interessiert an Optimierungspotenzialen (u. a. hinsichtlich Zeit, Kosten, Nachhaltigkeit) bei seinen Baustellenabläufen. Der Einsatz von Baurobotern bildet hierbei eine vielversprechende Option, welche u. a. im Hinblick auf aktuelle Entwicklungsstände (TRL), Einsatzpotenziale sowie technische, logistische und regulatorische Randbedingungen eruiert werden muss. Vor diesem Hintergrund war der BLB auf der Suche nach Beratungsleistungen im genannten Themenfeld. Die vorliegende Studie legt den aktuellen Stand von Technologien, Prozessen und Maschinen dar, zeigt Entwicklungstrends auf und ordnet die Möglichkeiten und Herausforderungen bezüglich eines zeitnahen und praxistauglichen Einsatzes von Baurobotiksystemen unter Beachtung geltender Regularien ein. Der Bericht fasst die Ergebnisse der Forschungs- und Entwicklungsarbeiten der GWT-TUD GmbH (GWT) zusammen, welche stellvertretend durch die beiden Projektleiter Prof. Dr.-Ing. Frank Will (Professur für Baumaschinen) und Prof. Dr.-Ing. Jens Otto (TU Dresden, Institut für Baubetriebswesen) erarbeitet wurden. Auftraggeber der Studie war der Bau- und Liegenschaftsbetrieb des Landes Nordrhein-Westfalen.

In dieser Thesis werden unterschiedliche Wege erläutert, Webanwendungen mit einem Cloud‐agnostischen Ansatz bereitzustellen. Ein Cloud‐agnostischer Ansatz zielt auf die Unabhängigkeit von einem bestimmten Cloud Service Provider (CSP) und dessen Technologien ab. Um dies zu ermöglichen, werden verschiedene Tools unter anderem hinsichtlich ihrer unterstützten Sprachen und Technologien, ihrer Modularität, ihres State und Secret Managements, ihres Bekanntheitsgrades und des Community Supports verglichen. Die Einführung erfolgt entlang der theoretischen Grundlagen, der Erläuterungen und Vorteile des Konzepts der Infrastructure‐as‐Code (IaC), anhand der Grundlagen zur imperativen und deklarativen Programmierung und mittels der Unterscheidung zwischen Domain‐Specific Languages und General‐Purpose Languages. In den folgenden Kapiteln folgt, bezogen auf die in dieser Thesis behandelten Beispiele Microsoft Azure (Azure) und Open Telekom Cloud (OTC), ein Vergleich der unterschiedlichen Möglichkeiten, Webanwendungen auf diesen Plattformen bereitzustellen. Dieser Ansatz soll anschließend durch eine Automatisierung mittels eines ausgewählten Frameworks als Prototyp anhand einer bestehenden Webanwendung implementiert werden. Zur Implementierung werden vorher die bekanntesten Frameworks auf Grundlage dieser Problemstellung verglichen und das passendste ausgewählt. Als Abschluss der Thesis folgt eine Zusammenfassung, in welcher die gelernten Kenntnisse und Erfahrungen im Umgang mit der Bereitstellung von Infrastruktur für Webanwendungen mittels IaC in einem Cloud‐agnostischen Einsatz dargelegt werden.:Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis 1 Einleitung 1.1 Problemstellung 1.2 Zielstellung 1.3 Aufbau der Arbeit 2 Theoretische Grundlagen 2.1 Prozess der Infrastrukturbereitstellung 2.2 Einführung Infrastructure‐as‐Code 2.3 Deklarativer und imperativer Ansatz 2.4 Domain‐Specific Languages 2.5 Abstraktionsebene 2.6 Stand der Technik 3 Analyse 3.1 Methodik und Umsetzung 3.2 Kriterien für einen Vergleich verschiedener IaC‐Werkzeuge 3.3 Kriterien für einen funktionalen Vergleich von Tools zur Orchestrierung 3.4 Detaillierterer Vergleich von Terraform und Pulumi 3.5 Docker zur Bereitstellung von Webanwendungen 4 Konzeption 4.1 Modellierung der Abstraktion 4.2 Betrachtung der Konzepte 4.3 Bewertung der Konzepte 5 Prototyp 5.1 Vorstellung der Voraussetzungen 5.2 Implementierung des Prototyps 5.3 Analyse des Prototyps 6 Fazit 6.1 Ausblick 6.2 Zusammenfassung Literaturverzeichnis Glossar