@thesis{Weidinger2021, author = {Weidinger, Patrizia}, title = {Untersuchung zur Sensordatenfusion durch einen Partikelfilter}, publisher = {Technische Hochschule Ingolstadt}, address = {Ingolstadt}, url = {http://nbn-resolving.de/urn:nbn:de:bvb:573-8692}, pages = {49, XXXIV}, school = {Technische Hochschule Ingolstadt}, year = {2021}, abstract = {F{\"u}r das Tracking von Objekten gilt der Kalmanfilter nur so lange als optimaler Algorithmus, wie seine restriktiven Annahmen erf{\"u}llt sind. Da in der Luftverteidigungsbranche hochagile Ziele getrackt werden, l{\"o}st der Kalmanfilter das Trackingproblem nicht mehr ideal und die Suche nach alternativen Algorithmen r{\"u}ckt immer mehr in den Fokus. Eine dieser Alternativen ist der Partikelfilter. Die vorliegende Arbeit stellt eine erste Untersuchung zur Verwendung eines Partikelfilters bei der MBDA Deutschland GmbH dar. Dabei liegt der Fokus auf der Fusion von Sensordaten. Das Ziel der Arbeit ist es, einen Partikelfilter zur Positionsbestimmung von mehreren Objekten in dem Phasenraum eines mathematischen Pendels durch mehrere Sensoren zu implementieren und die Ergebnisse der Datenfusion zu untersuchen. Aus den theoretischen Grundlagen des Kalman- und des Partikelfilters ergeben sich die drei wichtigsten Bestandteile eines Partikelfilters: Das Bewegungsmodell f{\"u}r die Positionssch{\"a}tzung der Partikel, das Messmodell f{\"u}r die Bewertung der Sch{\"a}tzung aufgrund der Messung und das Resampling f{\"u}r das Ersetzen schlecht bewerteter Partikel durch gut bewertete. Anschließend werden drei Leitfragen f{\"u}r die Arbeit formuliert, aus welchen sich die Anforderungen f{\"u}r die darauffolgende Implementierung ableiten. F{\"u}r die Realisierung des Partikelfilters werden zun{\"a}chst Aufbau und Ablauf des Partikelfilters festgelegt. Im Anschluss daran wird das Bewegungsmodell definiert, welches das Runge-Kutta-Verfahren zur L{\"o}sung der Differentialgleichung eines Pendels verwendet. Das Messmodell wird daraufhin so umgesetzt, dass alle Partikel, die sich in der N{\"a}he der Sensormessung befinden, ein Resampling erhalten. Dieses schiebt die Partikel in die Richtung der Messung. Partikel, die lange kein Resampling erhalten haben, werden gel{\"o}scht. Die Trackbildung wird im n{\"a}chsten Schritt mithilfe einer Self Organizing Map realisiert. Zuletzt sorgt die Visualisierung f{\"u}r ein {\"u}bersichtliches Testen der Ergebnisse. Die Implementierung zeigt, dass durch den Partikelfilter Daten von mehreren Sensoren fusioniert werden k{\"o}nnen, um Tracks von verschiedenen Objekten zu berechnen. Da diese Tracks in jedem Zeitschritt berechnet werden, k{\"o}nnen auch „Split Track-" und „Merge Track Events" festgestellt werden. Durch die anschließenden Tests kann gezeigt werden, dass die Anzahl der Tracks in 86.3 \% der F{\"a}lle korrekt bestimmt wird. Außerdem ist die Abweichung der berechneten zur tats{\"a}chlichen Position der Objekte in knapp 90 \% der F{\"a}lle niedriger als 0.15 Meter. Eine Verbesserung der Trackbildung ist durch eine Anpassung der Neuronen der Self Organizing Map m{\"o}glich. Die Untersuchung der Zusammenh{\"a}nge zwischen der Sensorgenauigkeit und der Qualit{\"a}t der Ergebnisse zeigt, dass die Ergebnisse besser sind, je h{\"o}her die Sensorgenauigkeit ist und je l{\"a}nger das Tracking andauert. Eine hohe Sensorgenauigkeit f{\"u}hrt allerdings zu einer deutlich l{\"a}ngeren Laufzeit. Dies kann durch eine Anpassung der Neuronen der Self Organizing Map verbessert werden. Die maximale Abweichung der berechneten von der tats{\"a}chlichen Position liegt bei einer mittleren Sensorgenauigkeit im Schnitt bei 0.19 Metern. Durch die Arbeit wird gezeigt, dass der Partikelfilter eine gute Alternative f{\"u}r den Kalmanfilter darstellen kann, wenn er auf geeignete Weise zur Anwendung gebracht wird. Die Sensordatenfusion ist erfolgreich gelungen. Auch die Ergebnisse der Trackbildung sind zufriedenstellend und k{\"o}nnen durch eine Anpassung der Parameter der Self Organizing Map weiter verbessert werden.}, language = {de} } @thesis{Weidinger2022, author = {Weidinger, Patrizia}, title = {Software testing reconsidered: Evaluation and comparison of symbolic execution tools in the context of aviation}, publisher = {Technische Hochschule Ingolstadt}, address = {Ingolstadt}, url = {http://nbn-resolving.de/urn:nbn:de:bvb:573-36036}, pages = {66, XLI}, school = {Technische Hochschule Ingolstadt}, year = {2022}, abstract = {Producing software in an aviation context means that there are very high testing requirements within the company and from outside by the customer or standards, as the consequences in case of an error can be very high. Fulfilling these requirements is a time-consuming process for the software developers. It is extremely demanding to cover all test cases in complex software systems, which is why a selection of the most important ones is necessary. Finding these can take a long time and is error-prone, as there is no systematic way and so brute force or intuition is often used to approach the issue. In order to ease the test effort for the developers and to make tests of higher quality, it is examined in this thesis to what extent Symbolic Execution can help here. Therefore, the possibilities of this techniques and the tools that are offered, are examined. In a theoretical discussion of the possibilities and limitations of Symbolic Execution, it is evaluated that Symbolic Execution offers good chances to improve the current testing strategy and provide a useful support to developers. The reason therefore is that test cases with high test coverage can be generated automatically and many runtime errors can be found. In order to see, which requirements need to be fulfilled to make a practical usage of Symbolic Execution tools reasonable, expert interviews are conducted. Resulting from these, requirements concerning functionality, performance, procurement, installation, and usage can be derived. In order to facilitate the search for a suitable Symbolic Execution tool for software developers in an aviation context, nineteen tools are being contemplated. Unfortunately, most of these tools are outdated or have dependencies that do not work in the given test environment. Therefore only Klee and Angr are executed and analysed in the following practical tests. The defined test cases are able to show, how the tools interact with the environment, how they react to more complex data constructs, if they can handle loops, how memory is being modelled, how good the constraint solving ability is and what errors can be detected. These practical tests as well as the results from the following comparison show that the requirements of the developers are only completely fulfilled by Klee. It's only disadvantage is the installation step, which is not as easy and takes some time. Angr has severe problems in handling loops, which leads to exceeding memory and the termination of the program by the scheduler. Also, hardly any errors are found by Angr with reasonable effort. By testing the source code of the communication between the different components of an MBDA internal project with Klee, it is detected that there are some hurdles that make the usage of the tool very difficult for real-world examples. First of all, Klee can not handle dynamically linked libraries. Also, the tool will not execute a program symbolically if there are LLVM intrinsics in any library that are not supported by Klee, regardless of whether there is a path that can reach them at all. All in all, Klee offers good possibilities to produce good and helpful results in a short amount of time, if the project under test is not using dynamically linked or too complex libraries. This restriction however leads to the fact, that is hard to use Klee in a real-world example in an aviation context. Nontheless, helpful tips on the installation, usage and error handling of Klee are appended to this thesis that show some lessons learned and give advises for best-practice in case someone wants to use Klee on a more fitting project.}, language = {en} }