Projects I am currently working on:
- CognitiveAR: Smart-City-Scale Cognitive Assistance
- EdgeRun: Edge Computing & Analysis Platform
- EMMA: Elastic MQTT Middleware
- MC2: Mini Computer Cluster
- CPS/IoT Ecosystem Cloud
CognitiveAR: Smart-City-Scale Cognitive Assistance
CognitiveAR is an end-to-end platform for enabling urban cognitive assistance applications using AR wearables. Imagine you are riding your bike wearing AR glasses. The glasses provide a head-up display (HUD) giving you information about the route, but also shows you the bounding boxes of cars and other cyclists in close proximity, that may not be in your field of view. Enabling these types of applications, that perform object detection on the glasses’ video feed, or access real-time access to sensor data from the environment, require a scalable edge computing platform.
We are developing a prototype for a smart city edge compute node that incorporates sensors, environmental context, and can be deployed in urban areas (2). We then leverage EdgeRun as the computing fabric (1) to deploy and operate AI services at the edge (1b) on the decentralized infrastructure (2). It uses EMMA to facilitate real-time device-to-device communication between glasses (3) and the edge node (2). We provide a set of AR device specific client libraries (3) to enable the seamless integration of our system with AR apps (4).
CognitiveAR has been funded by a Netidee 2020 project grant.
EdgeRun: Edge Computing & Analysis Platform
EdgeRun is a platform for edge computing. It is built around the idea of serverless edge computing, i.e., treating geo-distributed networked compute devices as a transparent compute fabric. Operational mechanisms from cloud computing, such as scheduling or auto-scaling, have several limitations when used in heterogeneous infrastructure scenarios. Operating data-intensive application, such as machine learning workflows, is particularly difficult. EdgeRun aims to address these issues, and provides an ecosystem of tools for analysing such systems.
EdgeRun comprises various loosely coupled components and tools. The core platform, tau is built on Kubernetes and OpenFaaS. At the heart sits a custom scheduler for edge-based serverless workloads called Skippy. For evaluating the scheduler, we have built a simulator using SimPy that simulates container-based severless environments called FaaS-Sim. To evaluate under different system parameters, we developed ether, an edge topology synthesizer.
- Waldemar Hummer (Conceptualization)
- Vinod Muthusamy (Conceptualization)
- Alexander Rashed (Initial implementation of the Skippy scheduler)
- Cynthia Marcelino (Data management API and system)
- Philipp Raith (Contributions to ether)
- Proximity-based autoscaling
- Decentralized API gateway and request routing
- Autonomous learning of scheduling parameters at runtime
- Rausch, T., Rashed, A., & Dustdar, S. (2021). Optimized container scheduling for data-intensive serverless edge computing. Future Generation Computer Systems, 114, 259–271. [Paper] [Preprint]
- Rausch, T., Lachner, C., Frangoudis, P. A., Raith, P., & Dustdar, S. (2020). Synthesizing Plausible Infrastructure Configurations for Evaluating Edge Computing Systems. In 3rd USENIX Workshop on Hot Topics in Edge Computing (HotEdge 20). USENIX Association. [Preprint]
- Rausch, T., Hummer, W., Muthusamy, V., Rashed, A., & Dustdar, S. (2019). Towards a Serverless Platform for Edge AI. In 2nd USENIX Workshop on Hot Topics in Edge Computing (HotEdge 19). USENIX Association. [Preprint]
- Rausch, T., & Dustdar, S. (2019). Edge Intelligence: The Convergence of Humans, Things, and AI. In 2019 IEEE International Conference on Cloud Engineering (IC2E 19). [Preprint]
EMMA: Elastic MQTT MiddlewAre
EMMA is a distributed MQTT middlerware that connects MQTT Clients to Brokers via Gateways to enable mobility and low-latency messaging via edge resources. It dynamically reconfigures the broker–client network based on their proximity to optimize latency. It is an effort to realize the vision of Osmotic Message-Oriented Middleware.
EMMA is written in Java using NIO and Netty. Brokers implement the MQTT protocol. EMMA also implements a control and monitoring protocol that allow a controller component to orchestrate the network. Brokers and Gateways have few dependencies and can be complied AOT using, for example, Graal Native to allow running it on constrained devices without a JVM. The controller is a Spring Boot application that is intended to run in the Cloud on a VM. It uses Redis to distribute routing tables across brokers.
- Manuel Geier (Concept for transactional migration of subscribers)
- Andreas Bruckner (Overhaul of monitoring and control protocol)
- On-demand provisioning of brokers to available resources
- Optimization of client–broker re-configurations
- Scalable network monitoring protocol and proximity detection
- Full implementation of the MQTT specification
- Fault tolerance and security mechanisms
- Rausch, T., Dustdar, S., & Ranjan, R. (2018). Osmotic Message-Oriented Middleware for the Internet of Things. IEEE Cloud Computing, 5(2), 17–25. [Preprint]
- Rausch, T., Nastic, S., & Dustdar, S. (2018). EMMA: Distributed QoS-Aware MQTT Middleware for Edge Computing Applications. In 2018 IEEE International Conference on Cloud Engineering (IC2E). [Preprint] [Presentation]
- Rausch, T. (2017). Message-oriented Middleware for Edge Computing Applications. In Proceedings of the 18th Doctoral Symposium of the 18th International Middleware Conference (pp. 3–4). [Preprint] [Presentation]
MC2: Mini Compute Cluster
Computational resources distributed at the edge of the network are the fundamental infrastructural component of edge computing. The operational scale of edge computing introduces new challenges for building and operating suitable computation platforms. Many application scenarios require edge computing resources to provide reliable response times while operating in dynamic and resource-constrained environments.
The MC2 is a prototype of a portable energy-aware, cluster-based edge computer that aims to address these challenges. It is portable because it is compact in size, and consumes energy at a scale that could be served by medium sized batteries. It is energy-aware because it provides a power-management runtime to access energy consumption data in real-time, and control the power state of its nodes. Finally, it is cluster-based because it comprises multiple physical nodes to provide reliable and scalable computing.
The project comprises several components used to operate and interact with the system, and define and execute experiments.
- Symmetry: Cluster management & system telemetry monitoring
- Workload Sandbox: Experimentation and analytics framework
- Hangar: Environment management tooling
- Valentin Bauer (Node environment management)
- Alexander Knoll (Hardware acquisition and setup)
- Jacob Palecek (First version of power monitoring)
- Philipp Raith (Improvements to frontend for monitoring and interactive experiments)
- Silvio Vasiljevic (Service management and monitoring)
- Dynamic control of node power state
- Simulation framework for energy-aware scheduling algorithms
- Optimization model for energy consumption
- Rausch, T., Raith, P., Pillai, P., & Dustdar, S. (2019). Demo: A System for Operating Energy-Aware Cloudlets. In 2019 IEEE/ACM Symposium on Edge Computing (SEC’19). IEEE. [Preprint]
- Rausch, T., Avasalcai, C., & Dustdar, S. (2018). Portable Energy-Aware Cluster-Based Edge Computers. In 2018 IEEE/ACM Symposium on Edge Computing (SEC’18). [Preprint] [Presentation]
CPS/IoT Ecosystem Cloud
A central part of the CPS/IoT Ecosystem architecture is a cloud that connects the living IoT labs. For the cloud infrastructure, we are building a small-scale OpenStack cluster at one of the TU.it data centers.
These are some projects I have been working on in the past.
CInsight: Predictive Analytics for Continuous Integration Workflows
Continuous Integration is a widespread practice, and while CI has evidently improved aspects of the software development process, errors during CI builds pose a threat to development efficiency. As an increasing amount of time goes into fixing such errors, failing builds can significantly impair the development process and become very costly By identifying characteristics of development practices that cause build failures, we can predict preliminary results for an integration. This helps developers react to possible problems even before a build is initiated, thereby saving time and resources. Also, a predictive analytics framework for CI builds could potentially be used for optimized operations of CI platforms, such as Travis or Bamboo.
The CInsight framework provides methods and tools to analyze CI build failures, link the code changes that triggered them, and use machine learning to build models for predicting CI build failures.
- Java OSS Travis-CI Build Failure Dataset
- Travis4J - A Travis-CI binding used to crawl Travis data.
- Jarvis - The CInsight framework (codenamed JARVIS)
Rausch, T. (2018). Java OSS Travis-CI Build Failure Dataset [Data set]. Zenodo. https://doi.org/10.5281/zenodo.1745638
Rausch, T., Hummer, W., Leitner, P., & Schulte, S. (2017). An Empirical Analysis of Build Failures in the Continuous Integration Workflows of Java-based Open-source Software. In Proceedings of the 14th International Conference on Mining Software Repositories. [Preprint] [Presentation]