(Anwendungs-)Projekte SE im Sommersemester 2026

Die Restauratoren der Münsterbauhütte müssen die Schäden an den zu restaurierenden Gebäuden erfassen, um die Kosten und die Durchführung einer Restaurierung zu planen. Dabei wird Stein für Stein in Augenschein genommen und für jeden eine Menge an Daten erfasst, um den aktuellen Zustand und die notwendigen Restaurierungsarbeiten zu dokumentieren.

Um die sehr aufwendige Datenerfassung mit Fotoapparat, Papier und Bleistift zu verbessern, wurde in vergangenen Projekten eine Windows-App entwickelt, die es ermöglicht, die Daten direkt am Tablet zu erfassen. Dabei werden die Kamera des Tabletts benutzt, um Fotos zu machen, diese mit einer Stifteingabe zu markieren und zu bearbeiten. Zurück im Büro, werden die so integriert erfassten Daten direkt mit der zentralen Datenbank abgeglichen.

Nachdem im vergangenen Jahr die App "aufgeräumt" und einige Teile modernisiert wurden, steht im Sommersemester die Entwicklung von neuen Anforderungen wie z.B. Verwaltung von "ToDos", „komplexerem Rechtekonzept" usw. an. Diese müssen teilweise zunächst in Zusammenarbeit mit Mitarbeitern der Bauhütte definiert bzw. verfeinert werden.

Die App ist in C# entwickelt worden.

Ansprechpartner:

• Alexander Raschke, Uni Ulm

Kontext

Seit einigen Jahren werden die Gremienwahlen an der Uni Ulm online über den Anbieter Polyas durchgeführt. Diese Vorgehensweise führt regelmäßig zu Diskussionen über die Sicherheit von online durchgeführten Wahlen. Grundsätzlich kann keine Onlinewahl alle Wahlgrundsätze einhalten und wurde daher schon 2009 vom Bundesverfassungsgericht für öffentliche Wahlen abgelehnt. Nichtsdestotrotz haben sich insbesondere Kryptologen damit beschäftigt, wie Wahlgrundsätze bei elektronischen Wahlen eingehalten werden können und haben dazu auch einige Ergebnisse veröffentlicht. Schließlich ist das Kernproblem der Sicherheit bei der Stimmabgabe (Stichwort: korrumpierter Rechner) noch nicht gelöst. Dennoch kann es bei Wahlen, wo die Gefahr der Manipulation aufgrund der nicht allzu großen Auswirkungen des Wahlausgangs, vorteilhaft sein, diese online bzw. elektronisch durchzuführen. Die Studierendenvertretung der Uni Ulm (StuVe) lehnte das in der Vergangenheit unter anderem aus Kostengründen und auch aus fehlender Transparenz der verwendeten Software ab. 

Ziele

In einem vorherigen Projekt wurden bereits viele Grundlagen geschaffen, ein für Gremienwahlen benutzbares open-source System zu erstellen. So wurden z.B. schon die kryptologischen Grundlagen und eine rudimentäre Oberfläche implementiert. In diesem Semester soll nun die Oberfläche ergänzt werden, so dass idealerweise die nächsten Gremienwahlen mit diesem Tool durchgeführt werden können. Wichtig dabe ist, dass alle möglichen Sicherheitsmechanismen (Überprüfung der eigenen Stimmabgabe, Überprüfung, ob die eigene Stimme in das Ergebnis eingeflossen ist, etc.) für die Benutzer möglichst einfach zugänglich und insbesondere mit Erklärungen auch verständlich sind. 

Links

Erste Anlaufstellen für Hintergrundwissen und Implementierungen sind

• https://www.tab-beim-bundestag.de/projekte_e-voting-alternative-wahlformen-und-ihre-absicherung.php
• https://csrc.nist.rip/groups/ST/e2evoting/documents/papers/EPSTEIN_TradeoffsPanel.pdf
• https://ieeexplore.ieee.org/document/10627283
• https://www.goodfirms.co/voting-software/blog/best-free-open-source-voting-software-solutions
• https://github.com/robinrowe/OpenVoter
• https://vote.heliosvoting.org/

Ansprechpartner:

• Alexander Raschke, Uni Ulm, Institut für SP

Blockchain technology enables the operation of distributed ledgers, a form of replicated database, in blockchain systems. Blockchain systems serve diverse use cases, including asset trading, seed funding, and recording of certificates, each imposing different quality requirements. Key requirements typically relate to degree of decentralization (DoD), scalability, and security. However, according to the blockchain trilemma, DoD, scalability, and security cannot be maximized simultaneously, necessitating Pareto-optimal configurations to balance trade-offs. The quality of a given system configuration can be investigated using model-based analysis. Recent research is developing various approaches to modeling and analyzing blockchain systems. 

Extending an existing simulation tool, the goal of this project is to implement tool support in the form of a modeling and analysis workbench for blockchain systems. The workbench should facilitate modeling a blockchain system configuration
through a Wizard based on system parameters like: 

• Number of Validating Nodes
• Inbound/Outbound Connections between Validating Nodes
• Number of Clients
• Connections between Clients and Validating Nodes
• Target, also called mining difficulty
• Max. Block Size
• Average Block Creation Interval
• Geographical Distribution of Nodes (Pairwise Latencies Between Nodes)

The workbench should allow for selecting several types of analyses for the given system configuration and then trigger the execution of existing analysis algorithms to investigate the dimensions of the blockchain trilemma. While scalability and security are the focus of the simulations, DoD is optional in this project. The workbench should help answer questions like: 

• What is the probable scalability of a given blockchain system configuration?
• How likely is an attack in a given blockchain system configuration?
• What configuration minimizes the likelihood of selected attacks?

In addition to configuring blockchain system models and starting analyses, the workbench should provide appropriate views to visualize the analysis results. Such visualizations could take the form of histograms, cumulative distribution functions, attack trees, or attack probabilities. Building upon the analysis of single quality requirements, the tool should allow for identifying Pareto-optimal configuration candidates to answer questions like:

• How does a given blockchain system configuration meet requirements set by a user in terms of scalability, security (and DoD) for different metrics?
• What is an optimal blockchain system configuration that best meets requirements set by a user in terms of scalability, security (and DoD) for different metrics?

Contact

• Prof. Dr. Robert Heinrich, Inst. für Softwaretechnik und Programmiersprachen
• Dr. Niclas Kanngießer, TUM/KIT

Context

Attack analysis is typically conducted by cybersecurity experts, who possess in-depth knowledge in this field. However, cybersecurity experts often do their job in the development phase, or even after the software system is released. When designing the software architectures or cyber-physical systems (CPSs), architects often miss the security aspects due to their knowledge.

Problem

The attacks can propagate through the system due to a misconfiguration or an unawareness of the implicit access control policies. Selecting an appropriate mitigation technique requires a lot of expert knowledge.

Tasks/Goals

• Research and develop an approach to use architectural analysis and a large language model (LLM) to mitigate an attack.
• Using architecture, we use Palladio Component Model (PCM) as the architectural description language, and ask LLM to identify the vulnerabilities and provide a suggestion to mitigate the vulnerabilities.
• Analyse the attack propagation with the proposed mitigation.

Technologies

• ReactJS
• Java
• Eclipse Modeling Framework
• Docker

Contact

• Lan Le, Inst. für Softwaretechnik und Programmiersprachen

Projektbeschreibung

Statische Analyse bezeichnet die Untersuchung von Programmen auf Laufzeiteigenschaften ohne diese tatsächlich auszuführen. Sie ist ein integraler Bestandteil moderner Softwareentwicklung und hilft beim Identifizieren von Fehlern, Sicherheitslücken oder dem Verbessern der Lesbarkeit. Compiler verwenden statische Analyse beispielsweise, um Typfehler zu vermeiden oder möglichst optimalen Code zu generieren. Entwicklungsumgebungen oder Language Server verwenden statische Analyse, um Ihre Funktionalität wie Refactorings oder Autovervollständigung zu realisieren (Siehe dazu auch Foliensätze statische Programmanalyse).

In diesem Projekt geht es um die Arbeit an und um flowR, einem Framework für die statische Analyse von R, einer statistischen Programmiersprache die häufig in der Datenanalyse und -visualisierung eingesetzt wird. Eine ausgiebige Analyse des Daten- und Kontrollflusses ermöglicht es flowR beispielsweise ein Programm nur auf die Teile zu reduzieren, die für die Generierung einer Grafik oder die Berechnung eines statistischen Modells relevant sind (das sogenannte Program Slicing) oder mittels Abstract Interpretation die Wertebereiche von Variablen zu bestimmen.

Über flowR

Aktuell kann flowR als Erweiterung für Visual Studio Code, Positron und RStudio, sowie direkt als Docker Image verwendet und ausprobiert werden. Folgende Zeile ermöglicht euch beispielsweise, flowR mit seinem read-evaluate-print loop zu erkunden:

docker run -it --rm eagleoutice/flowr:latest

Wenn ihr dann im REPL zum Beispiel den Datenflussgraph eines R Ausdrucks sehen wollt, könnt ihr folgendes eingeben:

R> :df! x <- 2 

Zum Verlassen, genügt ein :q flowR wird unter der GPLv3 Lizenz auf GitHub hauptsächlich in der Programmiersprache TypeScript entwickelt. Die ausführliche Dokumentation erfolgt über ein dediziertes und automatisch aktualisiertes Wiki und direkt im Code.

(Mögliche) Ziele

Dieses Semester ist das Anwendungsprojekt für flowR denkbar flexibel gestaltet und bietet eine Vielzahl an spannenden möglichen Bereichen (die sich so oder so ähnlich auch in Richtung einer Abschlussarbeit ausbauen lassen). Folgende Liste stellt einige mögliche Aufgabenbereichen vor, mit denen Ihr euch in flowR verwirklichen könnt. Die konkrete Zuteilung erfolgt dann zu Beginn des Projekts, je nach Interesse:

• Sicherheitsanalysen — Rs tief verwurzelte, dynamische Natur erlaubt zwar zum einen eine hohe Flexibilität und eine explorative Analyse von Daten, birgt aber auch gleichzeitig zahlreiche Risiken, vor allem wenn R-Code aus unsicheren Quellen ausgeführt wird. Daher möchten wir flowR um klassische Sicherheitsanalysen erweitern um Sicherheitslücken wie Code Injection oder Improper Input Validation zu erkennen.
• Transitive Paket-Analysen — flowR bietet mittlerweile eine fundierte Grundlage um den Daten- wie auch Kontrollfluss von R Skripten aber auch ganzen Paketen zu analysieren (und das ziemlich schnell, so benötigen wir mit 16 Kernen nur etwas mehr als eine Stunde um alle aktuellen Paketversionen zu analysieren). Allerdings verbleiben diese Ergebnisse gerade noch auf der Ebene einzelner Pakete und ignorieren die zusätzlichen Möglichkeiten von Paket-Übergreifenden Analysen, wie beispielsweise das nachverfolgen von Datenflüssen über Paketgrenzen hinweg.
• Dynamisches Laden von Code — Machen wir es kurz, R ist eine wundervolle Sprache. Kein Wunder, dass eine solche Sprache daher auch Möglichkeiten bietet, Code und auch bereits im Voraus berechnete Datensets durch diverse Binärformate dynamisch zu laden. Gerade solche Funktionen stellen allerdings eine große Herausforderung für statische Analysen dar, da der Code und seine Auswirkungen, bzw. die Daten so erst zur tatsächlichen Laufzeit bekannt sind. Gerade für die Fälle, in denen die geladenen Daten oder der Code bereits zur Analysezeit (wenn auch nur teilweise) vorliegen, möchten wir flowR dahingehend erweitern, dass solche dynamisch geladenen Inhalte auch in die Analyse einbezogen werden können.
• Erkennen impliziter Annahmen für externe Daten — Das durchschnittliche Analyse-Skript sieht wie folgt aus: Geladene Daten werden zunächst bereinigt, transformiert und anschließend analysiert oder visualisiert. Dabei werden allerdings häufig implizite Annahmen über die Struktur und den Inhalt der Daten getroffen (z.B. dass eine Spalte nur numerische Werte enthält oder dass keine fehlenden Werte vorliegen). Solche Annahmen können zu Fehlern führen, wenn die tatsächlichen Daten nicht den Erwartungen entsprechen oder sich später ändern. Fehler, welche sich häufig nicht oder nur sehr spät auch bei der Ausführung bemerkbar machen, da sie zwar die diese impliziten Annahmen verletzen, aber dennoch plausibel wirkende Werte produzieren. Mithilfe von flowR wollen wir nun Techniken entwickeln, um solche impliziten Annahmen statisch zu inferieren und in die Analyse einzubetten.
• Erklärbare Datenflussanalyse und API — Statische Programmanalyse ist ein wundervolles Themenfeld mit vielen komplexen Algorithmen und Techniken, die in einem emergenten Zusammenspiel die Analyse auch komplexer Programmsemantiken erlauben. Allerdings führt diese Komplexität auch dazu, dass die Details für Nutzer:innen von statischen Analysen häufig schwer nachvollziehbar sind und selbst vermeintlich einfache APIs eine Reihe an Annahmen Treffen, welche die "einfache" Nutzung erschweren. Hier geht es also darum, die bestehenden Analysen und APIs von flowR so zu erweitern und instrumentieren, dass diese die konkreten Schritte einer Analyse nachvollziehbar machen.
• Quellcode-Transformation — Statische Analyse wird häufig dafür genutzt um Fehler in Programmen zu finden oder Informationen über deren Verhalten zu gewinnen. Allerdings können wir viele Fehler bereits automatisch beheben (wie z.B. mit Quick-Fixes bei Lintern), Programme optimieren oder automatisiert instrumentieren um dann bei Ihrer Ausführung weitere Informationen zu erhalten. Dafür benötigen wir allerdings eine Möglichkeit, den R-Code auf syntaktischer Ebene transformieren und dann wieder zurück in Quellcode übersetzen zu können. Damit soll flowR um ein solches Quellcode-Transformations-Framework (vgl. Spoon) erweitert werden.

Interesse? Dann melde dich doch gerne bei mir und werde Teil des flowR Teams! 

Ansprechpartner

• Florian Sihler, Inst. für Softwaretechnik und Programmiersprachen

Project Description

This software project aims to develop an interactive Virtual X-Ray system that visualizes internal anatomical
structures by aligning a virtual skeletal model with a real person in real time. Using live camera input, the
system detects human body landmarks and tracks movement to accurately overlay a digital skeleton that
mirrors the user’s posture and motion. The project focuses on building a real-time processing pipeline that
integrates pose estimation, skeletal modeling, motion retargeting, and visualization. The resulting system
creates the illusion of an X-ray-like view, enabling intuitive exploration of human movement and anatomy.
The application is intended for educational, demonstrational, and visualization purposes rather than
diagnosis.

Project Goals

The primary goal of this project is to design and implement a robust real-time system that captures human
motion from a video stream and maps it onto a virtual skeletal representation. A key challenge lies in
achieving stable and anatomically plausible alignment between detected body landmarks and the virtual
skeleton, even under continuous movement. Another objective is to explore different visualization
techniques, such as semi-transparent overlays or projected skeletal renderings, to create a convincing “see-
through” effect. The project also aims to provide interactive features that allow users to inspect joints,
observe movement dynamics, and adjust visualization parameters in real time. Ensuring smooth
performance, low latency, and modular software architecture are essential for creating a compelling and
extensible demonstration.

Tech Stack

• Python
• PyTorch (pose estimation and motion processing)
• Computer vision & pose estimation models (e.g. MoveNet, OpenPose, MediaPipe Pose)
• OpenCV (camera input and real-time video processing)
• 3D skeleton models (e.g. Mixamo, public anatomical rigs)

Ansprechpartner

• Poonam Poonam, Inst. of Media Informatics 

Worum geht es?

Unser Chatbot „BPMNGen“ soll weiterentwickelt werden. Ziel ist es, natürlichsprachliche Beschreibungen und Anforderungen automatisch in grafische BPMN 2.0-Modelle umzuwandeln – und umgekehrt (Model to Text). Dabei stehen Modellqualität, Usability und Team-Kollaboration im Fokus.

Was soll verbessert/entwickelt werden?

• Höhere Modellqualität: korrekt, vollständig & BPMN 2.0-konform
• Kollaborative Modellierung – z. B. via Spracheingabe im Team
• Assistenzfunktionen: automatische Fehlererkennung, Vorschläge, Validierung
• RAG-Erweiterung (Wissenseinbindung über externe Quellen)
• Integration von Open-Source-LLMs
• Unterstützung von Modularisierung (Wiederverwendbare Prozessbausteine & bessere Wartbarkeit)
• Optimierung von BPMNGen (verbesserte Antwortqualität, intuitives UI, überarbeitetes Logo, …)

Was du mitnimmst:

• Praxiserfahrung mit LLMs & Prompt Engineering
• Arbeiten mit Open-Source-Modellierungs-Tools
• Umsetzung innovativer LLM-basierter Softwarelösungen
• Programmieren mit Angular & Node.js

Ansprechpartner

• Luca Hörner, Inst. für Datenbanken und Informationssysteme
• Maximilian Möller, Inst. für Datenbanken und Informationssysteme

Unternehmen stehen unter der DSGVO in der Pflicht, eine Dokumentation zu führen, wenn sie personenbezogene Daten verarbeiten. GRIPL nutzt ein LLM, um DSGVO-kritische Aktivitäten direkt in einem BPMN 2.0 Modell zu erkennen. GRIPL bietet außerdem die Möglichkeit zur automatischen Erstellung und Evaluation von Datensätzen aus BPMN 2.0 Modellen.

Technologien

• Next.js
• React Python
• OpenRouter

Weiterentwicklungen

• Textuelle Prozessbeschreibungen betrachten
• Erklärbarkeit der Entscheidungen verbessern
• Usability Anpassungen

Ansprechpartnerin

• Magdalena von Schwerin, Inst. für Datenbanken und Informationssysteme

Was ist der Sechs-Minuten-Gehtest?

• Der 6MWT ist ein einfacher Belastungstest im Gesundheitswesen.
• Misst die Distanz, die eine Person in sechs Minuten auf einer ebenen, harten Oberfläche schnell zurücklegen kann (ohne zu rennen).
• Wird häufig zur Beurteilung der funktionellen körperlichen Leistungsfähigkeit eingesetzt.

Ablauf des Tests

(siehe 1. Abbildung rechts)

Umsetzung als Cross-Plattform Flutter App

Nutzt Schrittzähler und manuelle Kalibrierung der Schrittlänge
Anmerkung: Wir hatten auch eine GPS-basierte Version, GPS funktioniert allerdings in-door nicht.

Eure Aufgaben

• Verbesserung der Benutzerfreundlichkeit: User-Story, Design, Passive-sensing, Lock-Screen …
• Testen neuer technischer Herangehensweisen zur Durchführung des Tests: Gyroscope, Accelerometer, …
• Umsetzung mit Google’s Cross-Plattform Framework Flutter für iOS und Android
• SE-Prozess (Softwareentwicklungsprozess)
• Details werden in Absprache mit dem Betreuer geklärt (z.B. Weiterentwicklung oder Neuentwicklung).

Contact

• Prof. Dr. Manfred Reichert, Inst. für Datenbank- und Informationssysteme
• Carsten Vogel, Universität Würzburg

Kontext

In diesem Projekt arbeitest du nicht nur an einer Simulation auf dem Bildschirm, sondern an einem echten VR-Fahrsimulator mit beweglicher Hardware. Ein motorisierter Rollstuhl in unserem Labor dient als Fahrzeugplattform und bewegt sich synchron zu einer VR-Fahrszene durch den Raum (ca. 4x4m). Während die Versuchsperson das Fahrzeug in VR erlebt, spürt sie Beschleunigungen und Kurvenkräfte. Das System wird bereits in aktuellen XR- und Mobilitätsforschungsprojekten eingesetzt und soll nun softwareseitig weiterentwickelt werden.

Ziel des Projekts ist die Entwicklung eines modernen Control-Dashboards in Unity für diesen Motion-Simulator. Eine API zwischen Unity, Arduino und den Motoren existiert bereits. Darauf aufbauend soll ein Digital-Twin-System entstehen, in dem der Rollstuhl als virtuelles Modell in Unity dargestellt und gesteuert werden kann. Dadurch lassen sich Bewegungsabläufe zuerst sicher im virtuellen Raum simulieren, bevor sie auf der echten Plattform ausgeführt werden.

Warum dieses Projekt interessant ist

• Arbeit an echter beweglicher Hardware statt nur an reiner Software
• Erfahrung mit Unity, VR und Digital-Twin-Konzepten
• Sichtbares Endergebnis im Labor statt nur Codeabgabe
• Einblick in aktuelle XR- und Mobilitätsforschung
• Möglichkeit, durch deinen technischen Beitrag später als Co-Author in einer wissenschaftlichen Publikation aufzutauchen

Projektüberblick

• Entwicklung eines Unity-basierten Control-Dashboards
• Aufbau eines Digital Twins des Motion-Simulators
• Planung und Simulation von Bewegungspfaden im virtuellen Raum
• Integration mit der bestehenden Arduino-basierten Rollstuhl API und der VR-Fahrszene in Unity

Vorkenntnisse

• Grundkenntnisse in Programmierung (z. B. Java, C#, Python)
• Interesse an Unity, VR, XR oder interaktiven Systemen
• Keine Hardware- oder Arduino-Vorkenntnisse notwendig

Das Projekt kann hybrid durchgeführt werden:
Entwicklung und Tests am Digital Twin sind remote möglich, während praktische Experimente mit dem realen Simulator im Labor stattfinden. 

Zu Beginn erhältst du ein klares Anforderungspaket für die zu entwickelnde Software, das im Verlauf gemeinsam weiterentwickelt werden kann.

Kontakt

• Pascal Jansen, Institut für Medieninformatik

Die zunehmende Komplexität von Hardware-Software-Systemen stellt unsere Gesellschaft vor eine große Herausforderung. Jeder Chip, jedes System und jede Anwendung muss entwickelt, implementiert und optimiert werden, um den steigenden Anforderungen gerecht zu werden. Dieser damit verbundene wachsende Aufwand wird oft als Design-Gap bezeichnet, da die Modellierung von Systemen und die Implementierung immer weiter auseinanderdriften.
Ein vielversprechender Ansatz, um diese Lücke zu schließen, ist die Verwendung von Model-Driven Architecture (MDA). MDA ermöglicht es, Modelle auf verschiedenen Abstraktionsebenen zu erstellen und diese dann in ausführbaren Code zu transformieren. Dieser Ansatz verspricht nicht nur eine höhere Effizienz, sondern auch eine größere Flexibilität bei der Entwicklung von komplexen Systemen. Eng verbunden mit MDA ist die formale Definition der im MDA Prozess verwendeten Modelle durch sogenannte Metamodelle und die automatische Generierung von Code – z.B. um die Erzeugung, das Lesen, das Transformieren und das Modifizieren der Modelle zu unterstützen. Meta-Modellierung und Code Generierung wird in sogenannten Meta-Modelling-Frameworks unterstützt.
Die Verwendung von MDA birgt jedoch auch Herausforderungen. Die derzeit auf dem Markt verfügbaren Meta-Modelling-Frameworks neigen dazu, sehr groß und komplex zu sein, was ihre Anwendung oft erschwert. Darüber hinaus ist der Entwurf und das Wiederverwenden von Metamodellen nicht immer trivial. Unsere jahrelange Erfahrung im Bereich MDA hat uns gezeigt, dass es hierfür spezielle Techniken und Ansätze benötigt, um die Komplexität zu reduzieren und die Effizienz zu steigern.
Im Rahmen dieses Projekts soll ein neues Framework MOMENT entwickelt werden, das die Vorteile von MDA mit der Notwendigkeit nach Einfachheit und Flexibilität kombiniert. MOMENT steht dabei für Meta Object Modeling and Engineering for Next-generation Technologies. Das Framework soll es ermöglichen, Modelle auf verschiedenen Abstraktionsebenen zu erstellen und diese dann in ausführbaren Code zu transformieren, ohne die Komplexität und den Aufwand zu erhöhen.

Ziel

Das zu entwickelnde Framework soll eine flexible und effiziente Modellierung auf verschiedenen Abstraktionsebenen ermöglichen, ohne die Komplexität und den Aufwand zu erhöhen. Es soll möglich sein, beliebig viele Abstraktionsebenen in einer Kaskade zu schalten, um die Modellierung von komplexen Systemen zu unterstützen. Basierend auf unserer Erfahrung im Bereich MDA haben wir erkannt, dass der Entwurf und die Wiederverwendung von Metamodellen oft Herausforderungen mit sich bringen. Wir haben daher Methoden entwickelt, die wir gerne in diesem neuen System der Forschung und Lehre  zur Verfügung stellen möchten, um die Modellierung und Wiederverwendung von Metamodellen zu erleichtern. Wir sind aber auch auf eure Ideen und Ansätze gespannt, welche die Welt der Metamodellierung noch weiter vereinfachen und bereichern können!

Technologie

Wir formulieren Anforderungen und diskutieren Lösungsansätze. Wir bleiben technologieoffen und sind bereit, verschiedene Ansätze zu prüfen. Unsere bisherigen Prototypen und ersten Ansätze können als Ausgangspunkt dienen, aber wir möchten das Team nicht auf eine bestimmte Technologie festlegen, bevor wir nicht eine umfassende Technologiebewertung durchgeführt haben. Diese könnte neue Lösungen aufdecken, die wir bisher noch nicht in Betracht gezogen haben.

Kontakt

• Raphael Kunz, Infineon, München

immersight entwickelt mit dem 3D-Workroom ein System, um Räume mittels 360°-Kamera zu erfassen, zu vermessen und virtuell zu betreten. Für diese Anwendung existiert keine native App - sondern eine Web-Anwendung basierend auf JavaScript, konkret ThreeJS. Dabei gibt es einen Edit-Mode (um Messungen vorzunehmen und 3D-Modelle zu platzieren, geht nur logged in) und einen Viewing-Mode, wenn man einen Virtuellen Raum einfach nur per Link teilt (anonym).

Hier ein Biespiel (Viewing-Mode): https://3d-showroom.com/projectlink/QyMVuVjQsO8jk3f148zs

Die Projekte im 3D-Workroom dienen meistens der Baustellendokumentation und -kommunikation. Das bedeutet, verschiedene Mitarbeiter eines Bauunternehmens machen zu verschiedenen Zeitpunkten mit der 360°-Kamera Aufnahmen vom Baufortschritt und laden diese Aufnahmen dann ins Projekt. Eine Vermessung und Begehung ist derzeit nur am PC, Laptop oder Tablet per Webbrowser möglich. Um einen noch immersiveren Zugang zu den virtuellen Räumen zu erhalten, soll es ermöglicht werden, diese Räume mittels XR-Brille zu betreten und ggf. mit dem Raum zu interagieren. Das heißt, den Raum auszumessen und Objekte einzusetzen.

Es soll der aktuelle JS-Code, der den virtuellen Raum lädt und darstellt, erweitert oder umgeschrieben werden auf WebXR (mittels ThreeJS), sodass man die Räume immersiv mit einer VR-Brille (Meta Quest oder GoogleXR) betrachten kann. Die WebXR Anwendung kann durch Aufrufen des Links zum Virtuellen Raum mittels XR-Device gestartet werden (Standalone-Mode). Genau so könnte aber der Virtuelle Raum auf einem PC/Laptop/Tablet geöffnet werden, dann über einen QR-Code ein XR-Client direkt auf dem XR-Device gestartet werden. Die Web-Anwendung auf dem Browser im PC/Laptop/Tablet könnte mittels Web-Schnittstelle mit dem XR-Device kommunizieren und Informationen (z.B. aktuelle Blickrichtung) zurücksenden (Client-Mode).

Der aktuelle JS-Code zum virtuellen Begehen hat einen Edit-Mode (User ist logged in) und so kann der Benutzer aktiv im Raum Veränderungen vornehmen. Das bedeutet, er kann Messungen im Raum machen oder auch 3D-Modelle platzieren. Diese Interaktion ist auch mittels XR-Brille möglich, da die meisten Brillen noch Controller für die Hände mitbringen. Es soll überprüft werden, in welchem Umfang Interaktionen im XR-Mode mit XR-Brille möglich sind.

Mit der 3D-Showroom Windows Software hat die Firma immersight noch einen Standalone Client für die Präsentation von Virtuellen Räumen, die häufig an einem PC+TV verwendet wird. Diese wird im Verkaufsprozess mit neuen Kunden verwendet. Hier ist ein Beispiel für einen virtuellen Raum: https://3d-showroom.com/kojelink/pp7xhH
Es ist möglich, eine Google Cardboard VR-Brille zu verwenden. Für Android wurde eine eigene App für diesen Zweck entwickelt (Panoramabrille-App). Diese App ist veraltet und die Funktion könnte durch den neuen WebXR-Client auch übernommen werden.

Ziele in Stufen

1. Virtuelle Räume sind mittels WebXR auf einer VR Brille (Meta Quest) erlebbar
2. Möglichkeiten der Interaktion prüfen, z.B. Objekte im Raum platzieren
3. Standalone Mode erweitern auf Client-Mode
4. WebXR-Client für Meta Quest auch an die 3D-Showroom Software anschließen

Kontakt

• Fabian K. O. Weiß, immersight GmbH