Generating audio from an article with Amazon Polly

Author: Silas Krause (sk295)


Reading multiple and detailed articles can become a little bit tiring. Listening to the same content, on the other hand, is more comfortable, can be done while driving, and is less straining for the eyes.
Therefore I decided to use this lecture to create a service that converts an article to an audio file using a Text-to-Speech service.

Technical Architecture

The input for the application is quite simple. The user only needs to provide a URL to the article. Then the main application fetches the contents of that URL and cuts out the unwanted markup. Then an audio file needs to be created. I chose the Amazon Polly TTS API and S3 as a file storage solution to try out Amazon Web Services.
To reduce multiple creations of the same article and load time, I intended to add a database that checks if there is already an audio file.
To interact with this application, I also needed a frontend that has an input field and dynamically renders the elements once the API endpoints send a response.

I built the app using NodeJS with the express because even though I do not have a lot of experience building backend applications, I know JavaScript well, and therefore I am familiar with node.
I decided to create three routes for my application. The index should serve the frontend. Additionally, I need two API endpoints, the first one to scrape the content from the URL, and the second one to generate the audio file.

Getting the content

Initially, I thought I could simply fetch the HTML from the source. I quickly discovered that some pages render the content on the client-side or have some kind of confirmation screen. That is why I needed a way to prerender the page. The best solution I found was Puppeteer. Puppeteer is a Headless Chrome Node.js API that runs Chromium headless and enables access to the rendered DOM. To reduce the load time, I blocked all third-party JavaScript.
Pruning the response to exclude everything but the content turned out to be a tedious task because every website structures their content differently. I ended up using unfluff, which is fine for most cases.


After the extraction, the text can be sent to the Polly API. At first, I was using the synthesizeSpeech method from the SDK. Aside from the parameters, this method accepts a callback function that can handle the response audio stream. That buffer can be stored in a file on the disk. While looking for a way to upload the audio file to S3 I found that there is a much simpler solution, which also eliminates the 3000 character limit of the synthesizeSpeech method. The Polly SDK also has an option to start a task using the method startSpeechSynthesisTask. This method excepts an additional parameter called ‘OutputS3BucketName’. After the task is completed. The output file is placed into the mentioned S3 bucket.
I really enjoyed seeing how this integration of different platform services simplifies the development.

In hindsight, a real consumer application might want to synthesize small snippets and stream them subsequently. That would almost eliminate the wait time, since generating an audio file and loading it can take up a lot of time for impatient users. However, I did not choose this path because I intended to create a cache with my database.

The Response object from the startSpeechSynthesisTask method contains a link to the file, but there are two issues.
The first problem is that S3 files are not public by default. You need to complete three different steps to make them publicly available.
At first, you need to unblock all public access in the permissions. Then you need to enable public access for ‘list objects’ for everyone. After that, a pocket policy needs to be created. The policy generator luckily makes that quite easy.

Even when public access is enabled, the asset cannot be loaded immediately because the generation takes a couple of seconds. I needed to notify and update the frontend. Eventually, I solved this by starting an interval once the audio is requested. The interval checks if the task has been completed and renders an audio element after it is completed.

The authentification for AWS had to be done using the Cognito service by creating an identity pool.


After the application was running successfully on my local machine, I had to deploy it. I chose the Platform-as-a-Service Platform on the IBM Cloud because I wanted to try out Cloud Foundry and I thought my simple express application was a good use case for this abstraction layer. I could have solved some parts of the app with a cloud function, but I do not need the control level of a virtual machine. Because Cloud Foundry requires a lot less configuration than a VM, it should be easy to deploy.
That is what I though.
I quickly ran into restrictions anyway. Except for the things I had to figure out due to my lack of knowledge of this platform, I had to spend a lot of time troubleshooting.
The biggest issue I faced was because of Puppeteer. At install time, the puppeteer package includes three versions of Chromium for Mac OS, Linux and Windows, which are all 150-250 MB large. The size exceeds the free tier limit and I had to upgrade. After that, I could not get Puppeteer running on the server, because the Ubuntu instance does not include all the debian packages that are necessary for running Chromium.
This really set me back. There is no way to install packages via sudo apt-get on PaaS and doing anything manually would eliminate the benefits of the simple deployment. I really thought I had reached the limits of Platform-as-a-Service until I discovered that you can use multiple buildpacks with cloud foundry. Even if they are not included on the IBM Cloud, by adding the Github repo.

    - nodejs_buildpack

This allows you to add an apt.yml file to specify the packages you want to install.
Afterward, I was able to run my application.


For tests, I chose to use mocha and chai. Except for a few modifications for the experimental modules I am using, this integration was straightforward. It uncovered a few error cases I was not considering before.


To sum up I can say that I learned a lot during this project, especially because a lot of things were completely new to me. But now I feel more confident to work with those tools and I want to continue to work on this project.
I can also recommend using cloud foundry. If you know how to deal with the restrictions and know your true environment conditions, it is pretty flexible and enjoyable to use.


A beginners approach at a cloud backed browser game


This article reflects my experiences while developing a real time browser-based game. The game of choice was Tic-Tac-Toe as it is straight forward to implement and does not have complex game mechanics. The following paragraphs explain my experiences I got while developing this game with a cloud-based infrastructure in mind. The article is not much of a manual on how to create a game in the cloud, it is more of a diary showcasing all the pitfalls and impressions I collected. This is more focused on beginner developers and first timers in projects as I share common pitfalls about my first bigger project which you should totally void.

To try out the prototype that I have created, check out the GitHub repository. There is a complete manual on how to start the application as well.

A simple game of Tic Tac Toe.

Initial project goal:

The initial goal of this cloud project was to create a simple browser game which automatically scales with increasing concurrent players. The key part for any game are game servers which players need to use to play against each other. Having no available game server means that no additional player can join in and have fun playing your game. The seemingless integration of additional game servers is a key point, no one wants to shut down the whole backend and bring it back up to just increase the server size. So, one goal was to achieve the seaming less integration of game servers and when they are not needed, the game servers should be removed without any hassle

The whole structure of the app is thought to fight against load in every possible part. For example, the frontend part, which consists of ReactJS should be relatively easy to scale. A load balancer would just redirect the request to the frontend to one of the available servers. The next server which then gets requested would be the matchmaking server. Here, several matchmaking servers should be free to choose from. However, it’s important to keep the connection to the same server every time, as these connections consist of socket connections which make it possible to transfer changes form the servers, which the frontend can’t access by default, in real time.

Technology stack

The technology used in this project is simple and easy to use. It mostly consists of technology I used in the past and I am quite familiar with. It saves a good amount of time not needing to be actively learning a new technology and using technology you are familiar with and which meets the requirements.

Frontend technology stack

For the frontend part I sided with ReactJS. It is more a personal preference to use ReactJS instead of Vue.js or plain HTML with JavaScript. ReactJS makes it easy to transform changes in data to the rendered HTML without ever writing a function to actively change your DOM by yourself. Changes to the DOM are easy and lightweight making it a great performance deal when doing frequent changes in the DOM. In my use case, a browser game, it was the perfect solution. Just get the data from the game server, push it into the fitting variable in the frontend and ReactJS magically adjusts according to the given data. ReactJS profits form huge community support as well. There are several packages that you can integrate in your project. In this project I integrated two rather famous packages, React-Router and React-Redux. React-Router makes routing between different pages easier without reloading the whole page. In my use case, the page consists of several components. Traditionally there is a header, a navigation bar and then all your information about the page you are on. If you are on the home page, it displays the home page, when you are on the about page, it displays the about page. With React-Router, it just loads the components that are changing. So, when going from the home page to the about page, only the component holding the about page re-renders. The header and navigation bar stays the same, as nothing changed there. It would be a huge waste of resources, re-rendering components which have not changed and are still used by the page. React-Redux is used to achieve a global state. Each React component has a state in which you store information. For example, the value of the input field in your form. But the problem that occurs when having multiple components is that you cannot pass this state to you siblings. Most likely you can pass the state to you children components, but that is it. React-Redux introduces global state that you can freely declare and use wherever you want. In this project it is used to save the information about the game you want to enter. From the lobby component you’d get the room name and the server name, then get redirected to the play component and the play component reads the information about the game you want to join from the global state. Talking about the play component, sockets are used to achieve real time communication between the client and the server. Socket.IO is used to establish a connection between the client and the game server. The game server holds a connection to both players. Each player’s interaction gets send to the game server, validated if needed, and then both players get the resulting game state form the game server back. Socket.IO is a proven framework with good community support and has great features such as rooms, which make it easy to use with a game project. Socket.IO’s rooms are used to create the different game rooms each server has. When a player joins a server, the game servers Socket.IO socket puts it into the matching room. All communication between the players in this room can now be easily emitted to just the room, and not all connected sockets.

The applications home page

Backend technology stack

The backend uses NodeJS servers with Express to provide an easy way to handle requests. Each server has its own different API-interfaces which are used by either other servers or for debugging purposes or general information. Additionally, the game servers and matchmaking servers have Socket.IO socket connections to communicate to the game server, the matchmaking server, or the frontend. With Socket.IO it is easy to listen to connects, disconnects and user defined room events, making managing the sockets not a total nightmare. Listening to disconnects is important for the matchmaking server to remove a game server from its list of available game servers and sends a request to the master server to check for the game server’s health. In case that the game server does not respond, the game server is removed from the master server’s server list as well, because the game server is not reachable anymore and therefore cannot be used to play matches on.

Two npm-packages have shown to be a great gift setting up these servers and making requests to other APIs simple. The first package Is node-fetch which, just like in plain JavaScript, has the fetch() method to asynchronously fetch information from an API. Unlike the standard JavaScript you use on your frontend, the fetch() method is not natively included in NodeJS. The other package is called minimist. It is a great convenience in reading the parameters the servers gets started with. To locally use multiple servers, each server needs adjustable ports. So, most servers created have a fitting parameter to set the port number.

Testing wise, Mocha and Chai are widely used in testing NodeJS applications. Mocha is a very common JavaScript test framework and Chai is a fitting assertion lobby extending Mocha’s asserting capabilities. Chai’s syntax is fairly easy to learn and easy to read as well.

Due to poor structural choices in development, most of the servers I created can not be tested without the others actually running. For example, the test case for the game server requires the master server to run, as a game servers first step is to register itself with a master server. The testing is set up, so that all required servers for testing are running before the test started.

Current state of the project

As of writing this article, the project is in a prototype state. All the servers work like they are meant to, and game servers can be seamlessly integrated into the running application. The whole application was deployed to Azure Virtual Machines and proved to work.

When trying out a different Azure service, like App Service, the application did not deploy as intended and would not work out of the box. When actually deciding on which Azure service to use, you need to check your different services for “compatibility”. For example, the game server uses two ports for sockets, one for the socket to connect with the player and the other one for a socket to connect to the matchmaking server. The Azure app service however only allows your application to use port 8080, so you either change your application to use that port, or completely switch to a different Azure service, virtual machine for example.

The biggest problem I encountered so far is to find a reliable way, to deploy my application to Azure Virtual Machines. Originally, I wanted to use Azure DevOps Pipelines which, after a successful build, then deploy the whole application to different virtual machines, but that did not work out right of the box as I thought. More on that in the ‘Cloud Integration’ chapter.

Application structure

The optional and aimed at structure looks like this:

A draft about the aimed structure of the application

Frontend, matchmaking and game server can be turned on and off depending on the current amount of players and the current load. Unfortunately, in the current state, there is no way implemented and tested, that one matchmaking server gets chosen when a player connects for the first time. It might work, but the frontend needs a couple of changes to dynamically change the address of the matchmaking server. At the moment its hard coded. The current structure looks more like this:

Current state of the structure.

Cloud Integration

Out of the several known cloud service providers, I sided with Microsoft Azure to get to know this service. During the cloud development lectures I have already tinkered AWS, IBM Cloud and Google Cloud but to further expand my basic knowledge about cloud services, I went with Azure. Adding to that, creating an Azure account gets you 170€ (200$) of free credit for the first 30 days, but you must verify yourself with a credit card. Payments only start if you switch your account from the free tier to a subscription-based tier.

Cloud Structure

Azure offers a variety of cloud services like virtual machines, load balancing clustered databases and Azure DevOps. Azure DevOps is basically your cloud enabled Jenkins instance allowing you to connect to your GitHub repository and automatically run pipelines depending the actions you take in your repository. For instance, when you push to the master branch of your repository, your DevOps pipeline automatically builds your projects, runs unit tests, and then can deploy your application to the Azure service of your choice. It is highly customizable and offers a variety of template applications to get started understanding how these pipelines work and are set up.

Cloud Pipelines

The development process should seemingless migrate from local development to deployment. Meaning, that every server can be set up locally, used for development and testing, and when finished, the changes can be pushed into the repository and a current build with all features gets set up automatically. The “dream pipeline” would look like this:

A deployed and running application is just a push away from being ready to use without ever setting up something by hand afterwards. Having such a powerful pipeline has several improvements while developing:

  • Automatic project building and running tests
  • Deployment happens automatically
  • All deployments are handled the same way and are consistently
  • Decreases time fiddling with deployments done by hand

Choosing the fitting cloud services is a key requirement before you actually start developing your application. I already mentioned the problem that I got myself into because I did not research the fitting cloud technologies beforehand. I’m not saying that the azure services I chose were the right and only fitting choice, the problem was, that I did not spent enough research on actually working out the different approaches I could take with Azure’s cloud services and what requirements the Azure services have. After a good amount of fiddling around, which got me to know the Azure App Service better, I understood that my current structure of the application simply could not use this service. The benefits from using Azure App Services would have been huge, as it would automatically scale depending on the load. It does however limit your abilities to directly debug and manage your application. It is not really possible to just login to your service via SSH, look at the logs or start/stop the application. A fully detailed comparison between the different services shows the azure documentation here: Azure Technology Choices

Project challenges

This chapter splits up into two different parts. Challenges in developing the application itself and the other part is about the challenges working on this project.

The biggest problem I encountered while developing the application was socket management in the frontend. This problem encountered, because two different components needed information from the incoming game event data of the active game. The ideal solution would be to share the socket across the application in a global state manner so that each component would set its listeners on the needed information. But that did not work out as a global state with React-Redux. The solution then was to actually get all the information in the game board component and then push it into a global state. The other component, the game status, would then retrieve it from the global state and update its values according to the data. This worked in the end and is sufficient for the prototype, but in a real-world production ready application, some sort of “socket-manager” or “socket-controller” would be needed to be implemented.

Another problem I encountered with the current prototype was testing. Especially the socket connections sometimes make it hard to create reliable tests as each test would need its own socket set up and ready to emit and retrieve data. The straight forward solution is to create “before” and “after” functions that ran before and after each test to setup sockets and afterwards closing them. In the test itself, only the listeners would be set, and data could be emitted through the set-up sockets. The really tricky part about this is to determine when to stop the test. A normal test calling a REST-API would be finished when the call was received and the data got evaluated. With sockets, especially when testing two player operations such as joining and emitting a player move, you have to carefully watch when to stop the test. Stopping the test is done by calling “done()”. In Mocha it’s a simple parameter that gets setup in the test. When “done()” is called, the tests stop. Sockets however can continue to receive information about events they are subscribed to. If two sockets have to receive the same event, on socket gets the information first and the second one last. The order of the sockets receiving information could be mixed up when networking does not deliver packages due packet loss for example. Meaning that the first socket receives the package after the second socket received the package. The test would end after the socket received the data, but the second socket still has to receive data and evaluate it. When running these tests locally, nothing like this occurred, but it is still a viable problem that can cause failure on the tests.

Most of the problems I encountered were on the more formal side of this project. A huge problem that I just realized when there were two to three weeks left until the presentation of the project was my time management concerning the development and deployment of the application. The development was going slower than I expected because of a slow month of August and a packed month of September in which my practical semester started meaning after sitting over 8 hours in front of a computer doing some sort of developing tasks, I had to spent my whole free time after to work on my project. I’d never expected it to be that hard to get things done after work, but after 8 hours, doesn’t matter what I’ve worked on, I simply wasn’t as concentrated, focused and quick while developing and driving the project forward, I was rather exhausted and that caused the project’s progress to slack.

As this is my first bigger project which I decided to do on my own, I got to know the difficulties planning and managing a project on my own, which led to quite some problems during the whole project. Time management got already mentioned, additionally the architectural side would need some great refactoring if the application ever would go into a productive environment. This happened due to poor knowledge about handling all these servers and components and just “coding away”.

The whole idea of this project was to develop something for the cloud. Unfortunately, I set my expectations quite too high for a single person, especially a beginner, to achieve something that big. I did however manage to create some kind of overview of my expectations. I already mentioned the pipeline that would get triggered on an action in the GitHub repository. This pipeline was made to capture everything I would need to research in order to create this kind of pipeline.

Without proper architectural knowledge it is quite hard to keep clean code and a reasonable structure inside each server application. For prototyping this is somewhat sufficient, but to actively develop and maintain a project, a clean structure and clean code is a must.

Learning for future projects

This being my first bigger project that results in actual software that has a real use-case, many different things have approached, whether they were good or bad. In the end the whole project thought me very valuable things about how I should approach the very next project during my studies. There are several key points that are worth pointing out.

The first one being a clear project scope that once defined, it should not suffer from huge changes. The project scope, especially for a timed project, needs to be adjusted just right to match the available man power and the available knowledge. Using new and not yet used technology is great, no arguing there, but getting started with new technology takes a lot of time, especially when going beyond the “tutorial” stuff. In my next project, I will make sure to account enough time for learning new stuff. This kind of goes hand in hand with proper architectural planning. Having no structure and plan to go along, makes it very hard to maintain and expand code. Other people may have a very hard time understanding the project at all.

Cloud architecture and cloud services come with the benefit of having huge resources on demand. It is definitely a topic that is going to be present for quite some time, so I’ll continue using them. Especially the benefits of cloud computing versus traditional computing, like load balancing and creating resources with one call or click, are very promising and easy to take care of resources and managing them. In combination with DevOps, an automatic deployment can save a huge amount of time over the time of developing the application.


Realization after finishing the project

During this project, I learned a lot about developing an application that makes, or should make, use of the cloud as a distributed platform enabling my application to scale and run however and wherever I want.

The key realization about project management is, that such a rather complex and feature rich application needs more time and more developers to get done in time with a releasable build. It is surly doable, but you really need to know your stuff. There would only be little time to get to know additional technologies so that you have enough time focusing on releasing a finished build that meets the requirements. It’s more a matter of knowing things and how they work, instead of being a high tier developer. A lot of time got spent on researching and trying things out than actually working with them.

Azure’s cloud services have shown me several possibilities to publish my application with totally different needs and benefits. Understand what you need and how you implement it, is something I have to dig deeper in my own research time. There is huge potential, that can be discovered, but you actually need time to integrate and get comfortable with cloud as your infrastructure provider.

The whole project made a lot of fun even though I just got around to make a working prototype and just got to touch the glimpse of cloud computing, I realized the huge potential for further projects and the necessity to get to work on cloud backed projects.

Perfekter Glühwein für Zuhause: Thermometer mit Raspberry Pi und AWS


Kein anderes Getränk ist mit Weihnachtsmärkten so verbunden wie Glühwein. Und so trinkt sich der ausschweifende Weihnachtsmarktbesucher im Laufe der Adventszeit von Stand zu Stand bis er schließlich am Ende des Jahres seinen Lieblingsstand gefunden hat. Doch auch daheim kann der perfekte Glühwein gelingen. 

Wir zeigen, wie man sich ein Glühweinthermoter mit Cloudanbindung selber baut, und so perfekten Glühwein und Komfort miteinander kombiniert. Und das ganz ohne gedrängte Weihnachtsmärkte und Mundschutz.



Unser dreiköpfiges Team hatte für die Vorlesung Software Development for Cloud Computing das Ziel, die Grundlagen der Entwicklung in einer Cloud Umgebung zu lernen und dabei ein Projekt auf die Beine zu stellen, welches diese Grundlagen in der Praxis umsetzt. Ein interessanter Aspekt der Cloud war für uns dabei die Bereitstellung einer überall erreichbaren Umgebung, über welche wir verschiedene Geräte miteinander kommunizieren lassen können.

Daher kam uns die Idee, ein Thermometer zu bauen, welches mit einem Raspberry Pi verbunden ist und wir die Daten über die Cloud verarbeiten und an ein Smartphone weiterleiten. Darüber soll es möglich sein, die aktuelle Temperatur abzulesen und eine Prognose für die Dauer bis zum Erreichen einer einstellbaren Temperatur zu stellen.

Unser Projekt besteht aus drei logischen Schichten. Unser Sensor stellt ein Raspberry Pi mit angeschlossenem Thermometer dar. Der Sensor dient der Feststellung der Flüssigkeitstemperatur, die wir anschließend in der zweiten Schicht verarbeiten. Unsere zweite Schicht stellt dabei eine EC2 Instanz bei AWS dar. Diese erledigt die Berechnung der Zielzeit und stellt einen Webserver für die dritte Schicht, der Datenanzeige bereit. Die Anzeige stellt Informationen und bietet Möglichkeiten der Steuerung des Systems. Es bestehen also bidirektionale Verbindungen, damit der Benutzer Konfigurationen am System unternehmen kann.


Der grundlegende Ablauf in unserem Projekt sollte also folgendermaßen aussehen:

Im ersten Schritt scannt das Smartphone einen QR-Code auf dem Raspberry Pi, damit die richtige Zuordnung von Raspi und Smartphone in der Cloud später gewährleistet werden kann. Als nächstes beginnt der Raspberry Pi, die Temperatur über das Thermometer auszulesen und schickt diese an die Cloud weiter. Sobald der Nutzer nun seine Zieltemperatur eingegeben hat und die Abfrage gestartet hat, wird dies im vierten Schritt mit der ID des Raspberry Pis an die Cloud übermittelt. Nun kann diese die Daten des Raspis mit der passenden ID verarbeiten, die Zeit errechnen und das Ergebnis an die App weiterleiten.


In unseren ersten Schritten wollten wir uns mit der Cloud vertraut machen und erste Instanzen darauf laufen lassen. Dabei entschieden wir uns für die Cloud von Amazon Web Services (AWS), da es zu dieser eine gute Dokumentation gibt und sie alle für uns notwendigen Komponenten bereitstellt. Zwar kostet die AWS Cloud im Gegensatz zur IBM Cloud auch für Studenten etwas, aber dies stellte für uns kein Problem dar, da wir von der HdM genug Credits zur Verfügung gestellt bekommen haben.

Bei unserem ersten Versuch, eine EC2 Instanz zu starten, stießen wir aber bereits auf einige Probleme. Der Grund dafür war, dass die AWS Cloud relativ komplex ist und sehr viele Möglichkeiten bietet, die Instanzen zu individualisieren und zu optimieren. Dies ist besonders für Einsteiger zu Beginn relativ überfordernd. Am meisten Probleme hatten wir mit dem Einstellen der Security Groups. Diese sind notwendig, damit der Zugriff auf den Server von außerhalb möglich ist. Erst nachdem wir den Zugriff auch über die verschiedenen Protokolle wie TCP und UDP geöffnet haben, konnten wir auf den Server zugreifen.

Als nächstes mussten wir unseren Raspberry Pi so erweitern, dass er die Temperatur messen kann. Dafür haben wir ein Thermometer gekauft, welches wir mit dem Raspberry Pi verkabeln.

Um nun die Temperatur auch zu verarbeiten, benötigten wir ein Skript auf dem Raspberry Pi. Wir entschieden uns hierbei für Python, stellten aber im Nachhinein fest, dass eine Sprache, welche nativ auf dem Gerät läuft, sich hier besser geeignet hätte. Dies hat damit zu tun, dass der Raspberry Pi in unserem Fall ja nur als Testobjekt fungiert, auf welchem Linux installiert ist. Eigentlich sollte es auch möglich sein, die Aufgabe des Raspberry Pis auf ein embedded System zu übertragen, welches nicht die Möglichkeit hat, Python zu nutzen. Hätten wir dies im Vorhinein beachtet, wäre der Übergang vom Raspberry Pi zu embedded Systems einfacher.

Das Thermometer schreibt die ganze Zeit die aktuelle Temperatur in eine Datei auf dem Raspi. Diese lesen wir mit dem Skript jede Sekunde aus und schicken sie dann gemeinsam mit der ID des Raspis an den Server.

Im weiteren Verlauf des Projekts beschäftigten wir uns mehr mit der Serverseite in der Cloud. Wir entschieden uns für eine Node.js-Lösung, welche in der EC2 Instanz läuft, da Node.js mit get und post requests alle von uns benötigten Kommunikationsmittel zwischen dem Raspberry Pi und dem Smartphone bereitstellt. Auch im Nachhinein erwies sich Node.js als eine gute Wahl, da das Aufsetzen des Webservers keinerlei Probleme bereitet hat und die Kommunikation auch mit dem Python Skript auf dem Raspi einwandfrei geklappt hat.

Unser technischer Ablauf und die Kommunikation unter den Geräten sah nun folgendermaßen aus:


Zu Beginn des Projekts bestand unser Frontend nur aus einer Webseite, welche die Temperatur des Thermometers anzeigen sollte. Später erweiterten wir diese mit einem Zeit-Temperatur Graph und einem Thermometer zur Darstellung der Temperatur. Dies ließ sich mit HTML, CSS und etwas JavaScript relativ simpel realisieren. Später wurde diese Ansicht durch eine Android App erweitert. Diese stellt eine mobile Möglichkeit dar, sich über den aktuellen Stand zu informieren. Technisch gesehen handelt es sich hierbei um eine WebView, die die Webseite mobil anzeigt.

Dieser Weg, erst eine leicht wartbare Webseite zu erstellen und diese anschließend per WebView auf dem Smartphone aufzurufen erwies sich als gute Idee. So konnten wir uns erst um die Funktionalität der Geschäftslogik konzentrieren und diese anschließend ohne viel Code auf dem Handy nutzen. Jedoch muss man die Optimierung für verschiedene Geräte dann nicht in der App selbst, sondern in der Website vornehmen, was etwas mühsamer ist als in Java für Android.


Ein zentraler Wunsch war es, eine zeitliche Abschätzung zu erhalten, wann nach aktuellem Temperaturtrend die Zieltemperatur erreicht wird. 

Dafür haben wir zuerst eine Beispielmessung eines Temperaturverlaufs durchgeführt. Eine Analyse verschiedener Trendlinien hat ergeben, dass sich eine quadratische Regression am Besten eignet. Bei der Auswahl haben wir ein besonderes Augenmerk auf die Genauigkeit der Zeitabschätzung nach kurzer Zeit gelegt, sodass wir bereits relativ früh eine gute Abschätzung bekommen. 

Die eigentliche Berechnung erfolgte dann in 3 Schritten. Zuerst wurden die Mittelwerte der Messwerte ermittelt und mit diesen nach den Formeln der quadratischen Regression die Faktoren einer quadratischen Gleichung bestimmt. Anhand dieser konnten wir nun den Schnittpunkt mit der gewünschten Zieltemperatur berechnen. Vorteil dieser Variante ist es, dass wir auch negative Temperaturtrends, sowie andere Zieltemperaturen verarbeiten können. Bei der praktischen Anwendung stellte sich jedoch heraus, dass das System einige Schwachstellen aufweist. So können gleichbleibende Temperaturen, die vor allem in der Anfangsphase einer Erhitzung auftreten, die Berechnung sehr ins Schwanken bringen, sodass manchmal für längere Zeit keine Zielzeit berechnet werden kann. Auch kommt es zu teils starken Schwankungen im Verlauf einer Messung. Diese Probleme können jedoch durch eine Bereinigung der Daten im Voraus gelöst werden.


Wir haben im Laufe des Projektes natürlich nicht nur viel Mathe gemacht, sondern auch sehr viel über Cloud Computing gelernt. Für einen Anfänger, der vorher noch nie mit AWS in Kontakt kam, ist der Einstieg ziemlich überfordernd. Es gibt deutlich einsteigerfreundliche IaaS-Anbieter wie z.B. die IBM-Cloud.

Was unseren Server angeht, sind wir auch recht zufrieden mit unserer Wahl von Node.js als Web-Backend. Node.js bietet den Vorteil, dass es sehr einfach ist, einen Webserver aufzusetzen, der auf Anfragen hört und gleichzeitig eine Webseite liefern kann. Braucht man mehr Performance und stellt viele parallele Anfragen an den Server, würde es sich lohnen einen Server in Go aufzusetzen. Dasselbe gilt für unseren Raspberry Pi. Das Python-Skript zu schreiben ging ziemlich schnell, aber auch hier könnte man auf eine performantere Lösung in C++ einsetzen. 

Durch eine erprobte Zielberechnung hat unser Thermometer deutlich an Funktionalität gewonnen und kann für nun für verschiedene Temperaturen eingesetzt werden.

Unser Projekt war ganz klar auf Anfänger ausgerichtet. So wurden bereits genutzte und bekannte Technologien mit neuen Technologien der Cloud kombiniert. Dabei konnte der Funktionsumfang von AWS natürlich nicht vollständig ausgenutzt werden. Jedoch haben wir uns Schritt für Schritt an der Cloud bedient und so einen ersten Einblick in die Welt von IaaS erhalten.

Geschrieben von: Nikolai Thees, Michael Partes & Joshua Gertheiss

Get car location using Raspberry Pi and Google Cloud IoT Core

Project idea

Have you ever been in the situation, that you parked your car somewhere in the city and some hours later, you couldn’t remember where you parked it? You may wish to have an application on your smartphone, which is able to locate your car. From this consideration, the development of CarFuelLocate started.


Using CarFuelLocate you are not only able to track the current location of your car, you are also able to track the fuel level of your car. Moreover you’re also able to locate the cheapest and the closest gas station, according to the matching fuel type.

CarFuelLocate Web Application


We equiped our car with a Raspberry Pi 3B to get the telemetry data of the car. We expanded the Raspberry Pi with a expension board, which made Bluetooth, UMTS and GPS connections through a serial interface possible. The retrieving of the vehicle data (e.g. fuel level) works through a OBD2 diagnostic device, which is connected to the Blutotooth interface of the Raspberry Pi extension board.

The processing of these data is made through a simple Python script, which is running on the Raspberry Pi, which sends the data to the Google Cloud Platfrom IoT Core, where it will be processed by a cloud function (we will look at this later).

Architecture and cloud components

CarFuelLocate consists of multiple parts. The Raspberry Pi, a simple Node.js backend , a simple Vue.js frontend and several cloud services and apis.

basic architecture of CarFuelLocate

Raspberry Pi

As already told, the Raspberry Pi collects the vehicle telemetry data and sends them to the Google Cloud IoT Core.

Cloud IoT Core and Cloud Functions

The Google Cloud IoT Core is a service that allows you to manage IoT devices and collect real time data of the devices. In our use case, it basically acts as an authentication service for the Raspberry Pi.

The Python script, running on the Raspberry Pi, sends it’s requests to the Google Cloud, where it is authenticated using the Cloud IoT Core. The request is served by a cloud function, which writes the data (e.g. the position of the car) directly into the Cloud Firestore database.

async function updateLocation(data,deviceId){
  const docRef = db.collection('location').doc(deviceId);
  await docRef.set({
    lon: data.lon,

example code for a cloud function, saving the location to the database

When a user wants to connect his Raspberry Pi for the first time, he receives a token from the web application, which he has to enter into the Python application on the Raspberry Pi, which starts the registration.

During this process the Raspberry Pi generates a RSA keypair and appends his public key to the Cloud IoT platform, which assignes a individual device id, which is used to assign the device to a specific user.

Cloud Firestore

The Cloud Firestore stores all the user information, including the data sent by the Raspberry Pi (e.g. location) and the data, that is configurable by the user, through the frontend (e.g. fuel type).

The Cloud Firestore is accessed by the Cloud Functions and the Node.js backend.

Google Cloud Identity platform

We used the Google Cloud Identity platform as OAuth provider, so that users are able to login with their Google Account.

Node.js Express backend

The application consists of a simple Node.js Express backend, which handels the API requests by the frontend and handles the one-time Raspberry Pi user registration.

The backend is deployed in an App Engine, which is pretty easy becaue you basically just have to upload the code and the Google Cloud Platform does the rest. This gives us the possibility to focus on our code and the responsibility to operate the Node.js server rests in the hands of Google.

Vue.js frontend

A simple Vue.js frontend serves the car related data (e.g. location, fuel level, cheapest gas stations) with a responsive web application.

CarFuelLocate web application

The frontend is also deployed in an Google Cloud App Engine.


The application is able to show the cheapest and the nearest gas station. The backend is accessing the “Tankerkönig”-API to get the desired data about the gas stations. The API lists all gas stations in Germany, their position, and the price details.

The frontend uses the Google Maps API to display the car and the gas stations on a interactive map.


We used the HdM GitLab not only for version control, we used the CI/CD functionality to perform automated testing and an automated build and deployment process. We used a shared GitLab runner, which was offered by our university.

Our pipeline, that is triggered on each commit, consists of automatically launched tests and an automated deployment process, which deploys the App Engines to the Google Cloud Platfrom.

We developed on different branches. The development branches were deployed to different development App Engine instances. By merging the changes to the master branch, the changes were deployed to the production environment.


During the development, we run into several challenges and learned a lot.

At the beginning we completly developed CarFuelLocate without the Cloud IoT Platfom. We defined a token on the Raspberry Pi which was than copied into the frontend of our web application. Doing this it was possible to send requests to the backend, by unauthorized clients. By brute forcing the token, an attacker would be able to manipulate the user data.

As we noticed our security problem, we switched to the Cloud IoT Platform. Now this kind of attack isn’t possible anymore. The individual device id is now assigned to a RSA keypair. If an attacker guesses the device id, he still isn’t able to manipulate user data, because he isn’t in possession of the RSA keypair.

Another attack that would be conceivable is that an attacker guesses the one-time token, that is shown the user, during the first-time device registration in the web application. So an attacker could connect his own client to the account of another persoen, during the period where the real user tries to connect his own Raspberry Pi. This could be solved by providing a confirmation query for the real user in the web application, asking whether he really wants to connect this Raspberry Pi to his account.

Google Cloud Platform

There is no specific point, why we used the Google Platform. Our decision is based on serveral points.

First of we learned a lot about the IBM Cloud and AWS in our Lecture Software Development for Cloud Computing and wanted to learn how other cloud providers work. Another point is, that we wanted to develop the whole project with one service provider and the Google Cloud Platfrom offers everything we wanted.

Alternatively we could have used Amazon Web Services and use their IoT platform, in combination with EC2 instances and a Amazon DocumentDB for our web application. Our project would also be able using the IoT platform of the IBM Cloud. Amazon and IBM doesn’t offer a map service (like Google Mpas), but we would still be able to use the Google Maps API in combination with the IBM Cloud or AWS, or we could have used OpenStreetMap.

There are many ways to develop a cloud based IoT application, our procedure is only one way.

Sicherheitssysteme in der Raumfahrt


Die heutige Raumfahrt oder auch allgemein Raumfahrt ist ein sehr komplexes und vielschichtiges Thema. Nicht grundlos werden umgangssprachlich schwierige Themen als “Raketenwissenschaften” bezeichnet. Dieser Artikel möchte nicht die Raumfahrt in ihrer Gänze beschreiben sondern nur einen sehr kleinen Teil im Bereich der Sicherheit beleuchten. Hierfür wurden sich vor allem auf den Start einer Rakete und die Landung mit einer Raumkapsel konzentriert. Natürlich gibt es noch sehr viel mehr Sicherheitskonzepte in der Raumfahrt, als in diesem Artikel beschrieben werden. Zusätzlich werden nicht alle, sondern nur ein paar der Sicherheitssysteme angeschaut, da auch hier dauerhaft geforscht wird und was heute als Stand der Technik gilt morgen schon veraltet sein kann. Deshalb sind die hier beschriebenen Systeme auch keine puren Prototypen sondern eher etablierte Systeme, welche bereits seit Jahren im Einsatz sind, mit eventuellen Ausblicken auf zukünftige oder kürzlich neu erprobten Abwandlungen und Ideen.

Dieser Artikel ist außerdem nicht als Anleitung oder detailgetreue, vollständige Erklärung der hier beschriebenen Systeme aufzufassen, sondern soll lediglich einen Überblick über die Systeme schaffen und eventuell Lust machen sich mehr mit den Systemen und der Raumfahrt im allgemeinen zu beschäftigen.

Warum eigentlich Raketen?

Wenn man sich eine Weile mit der Raumfahrt beschäftigt stößt man schnell auf Ideen und Konzepte für verschiedene Systeme in den Weltraum, beziehungsweise in den Orbit zu gelangen. Hierbei finden sich immer wieder Ideen wie beispielsweise spaceelevator (spacelift), skyhooks oder space launch cannons. Viele dieser Systeme bieten eine auf Dauer kostengünstige alternative Fracht in den Orbit zu transportieren. Wir setzen immer noch global und fast ohne ausnahmen auf Raketen. Dabei haben Raketen eigentlich sehr viele Nachteile.

Offensichtlicher weise sind Raketen extrem Laut und der Treibstoff der beim Start verbrannt wird ist unter umständen sehr umweltschädlich. Raketen eignen sich dementsprechend nicht dafür mitten in der Stadt abgeschossen zu werden sondern es müssen extra riesen große Gebiete nur für die Starts freigeräumt werden. Außerdem sind Raketen sehr teuer. Geschätzte Preise für den Start einer Ariane 5 liegen bei 150-200 Millionen US-Dollar. Für die kleinere kommerzielle Falcon 9 immerhin noch bei etwa 62 Millionen US-Dollar. Dazu kommt noch, dass nur ein Bruchteil der Masse effektive Nutzlast ist. So wiegt eine Falcon 9 etwa 550 Tonnen. Aber nur etwa 22,8 Tonnen davon kommen am Ende im niedrigen Erdorbit (low earth orbit, kurz LEO) an. Das entspricht gerade einmal 4% der Gesamtmasse. Als vergleich ist das etwa, wie wenn man mit einem Großen LKW auf der Straße 100 kg Fracht transportieren würde. Und zur Fracht würden auch Fahrer und Kabine zählen. Ergänzend kommt noch dazu, dass wir den LKW nachdem wir am Ziel angekommen sind einfach wegschmeißen würden, da Raketen zumindest bisher nicht wieder verwendbar waren. Und selbst bei der Falcon 9 von SpaceX, welche zu teilen wieder verwendbar ist, wird immer noch ein relativ großer Teil weggeschmissen und die Einsparungen in den Kosten belaufen sich auch nur auf einen recht geringen Anteil. Als wäre das noch nicht genug ist ein Flug mit einer Rakete auch noch super gefährlich. Im Prinzip sitzt man auf einer fortlaufenden Explosion und hunderten Tonnen Sprengstoff. Wenn hierbei ein Fehler auftritt ist die Rakete meistens nicht mehr zu retten. Warum also nutzen wir immer noch Raketen?
Die Antworten hierauf sind tatsächlich relativ einfach. Zuerst einmal sind Raketen einfach super schnell. Es werden gerade einmal so etwa 10 Minuten benötigt um in den Weltraum zu gelangen. Spricht man vom Weltraum ist sofort noch der Vorteil vorhanden, dass Raketen auch im Vakuum funktionieren. Sie bringen alles mit was sie zur Fortbewegung benötigen, im Gegensatz zu einem Flugzeug. Außerdem haben wir heute einfach ein sehr großes Wissen über Raketen und wie wir sie effektiv nutzen können. Sprich sie sind technologisch sehr gut machbar. Diese technologische Grundlage haben wir vor allem dem zweiten Weltkrieg und dem kalten Krieg zu verdanken, denn hier wurde im Spacerace natürlich auf Raketen gesetzt, da diese auch wunderbar als Waffe oder Langstreckenträger für Atombomben eingesetzt werden können. Kurz gesagt, dass wir heute Raketen verwenden ist vor allem Historisch so gewachsen.

Wie funktionieren Raktenstarts?

Der Start einer Rakete lässt sich grundlegend in mehrere Stufen unterteilen. Beim erreichen jeder dieser Stufen wird meist ein weiterer Teil des launchvehicles abgetrennt, sodass Die Rakete insgesamt an Gewicht verliert und leichter wird. Für was sollte man beispielsweise einen leeren Treibstofftank noch weiter mit sich herumschleppen, wenn dieser nicht mehr benötigt wird. Die obere Grafik zeigt einen normalen Ablauf beim Start einer Soyuz Rakete. Es wird aufgelistet, wann welcher Teil der Rakete abgetrennt wird und ungefähr die Zeit wann dies geschieht. Der Aufbau einer Soyuz Rakete mit den einzelnen Teilen, den sogenannten Stages, ist im unteren Bild zu sehen.

Launch Escape System (LES)

Wie bereits bei den Nachteilen von Rakete erwähnt, sind Raketen meist nicht mehr zu retten, wenn beim Start irgendetwas schief gehen sollte. Und da dies meist in einer sehr großen Explosion endet bleibt von der Rakete auch von der Fracht nicht sehr viel übrig. Deshalb wird an der Rakete wenn man die Fracht sichern möchte meist ein sogenanntes launch escape system installiert. Dieses LES ist im Prinzip eine oder mehrere weitere kleine Raketen, welche die Fracht von der Trägerrakete entfernen und in Sicherheit bringen sollen. Hierfür wird die Kapsel oder Fracht von der Trägerrakete entkoppelt, wie es eigentlich erst im Orbit passieren sollte und die Raketen des LES gezündet. Sobald die Raketen des LES ausgebrannt sind wird es ebenfalls von der Kapsel abgetrennt und die Kapsel kann mithilfe der für die Landung vorgesehenen Fallschirme sanft zu Boden gleiten.

Bei der Umsetzung des LES wird inzwischen auf zwei verschiedene Methoden gesetzt. Zum einen die klassische Tower Methode, bei der oben auf der Kapsel ein Tower installiert wir der das LES und auch ein paar andere Systeme enthält. Zum anderen gibt es das inzwischen von ein paar Fahrzeugen eingesetzte Pusher System, bei dem das LES in die Kapsel integriert ist.

Das klassische Tower-Konzept hat die Vorteile, dass es während des Fluges abgeworfen werden kann, sobald es nicht mehr gebraucht wird und somit die Last der Rakete verringert wird. Außerdem benötigt es keinen extra Platz in der Kapsel und kann theoretisch auf jede mögliche Frachtkapsel oben drauf gesetzt werden, solange die Adapter stimmen. Ein Großer Nachteil des Towers ist allerdings, dass wenn man ihn abstößt ist er unwiederbringlich weg.

Der Vorteil des integrierten Pusher Systems, wenn man es nicht als LES verwendet ist, dass es auch als Bremsraketen bei der Landung oder als Steuerdüsen im Weltraum verwendet werden kann. Es bleibt außerdem den ganzen Flug über verfügbar, für den Fall dass doch irgendwann noch etwas schief geht.

Zusammenfassend kann man sagen, dass beide Systeme ihre Vor- und Nachteile haben. Was allerdings bei beiden System hinzu kommt, ist dass sie beide auf einer Technologie basieren, für welche sie selbst die Notlösung bei Fehlern bieten, nämlich den Raketen an sich. Ein LES basiert auf der Fortbewegung durch Rakete und hat ähnliche Anfälligkeiten und Nachteile. Tatsächlich gab es zum glück aber auch nur sehr wenige Fälle bei denen ein LES wirklich eingesetzt werden musste.

Atmospheric reentry

Während man sich beim Flug in den Orbit vorwiegend darüber Gedanken machen muss, wie man die benötigte Geschwindigkeit aufbauen kann um in einem Stabilen Orbit zu bleiben, muss man sich bei der Landung darum kümmern genau diese Geschwindigkeit sicher wieder abzubauen. Neben der aktiven Möglichkeit Schub entgegengesetzt der aktuellen Flugbahn zugeben und somit die Geschwindigkeit zu verringern gibt es noch die passive Möglichkeit lediglich durch Reibung die Geschwindigkeit zu verringern. Dies hat den Vorteil, dass kein zusätzlicher Treibstoff mehr gebraucht wird, welcher in erster Linie auch mit in den Orbit gebracht werden müsste. Der offensichtliche Nachteil ist, dass extreme Geschwindigkeiten nur durch Luftreibung abgebaut werden und somit extreme Hitze entsteht. Auch wenn diese Hitze dafür sorgt, dass kleine Meteoriten in der Atmosphäre verglühen und somit keinen Schaden auf der Oberfläche anrichten können, soll eben dieses Verglühen bei den Raumkapseln welche aus dem Orbit zurückkehren verhindert werden.

Damit die Kapsel nun die extreme Hitze aushalten kann muss sie auf die eine oder andere Weise widerstandsfähig gemacht werden. Dies kann entweder durch aktives, passives oder sogenanntes ablatives cooling oder aber durch heat absorption geschehen.

Unter aktiver und passiver Kühlung sind relative klassische Kühlungssysteme. Dabei wird die Hitze, welche von der Struktur aufgenommen wird wieder nach und nach an die Umgebung abgegeben. Dies kann entweder passiv passieren, wenn der Wärmeaustausch einfach durch die Struktur selbst stattfindet und nicht weiter eingegriffen wird. Oder aktiv, wenn zum Beispiel Kühlflüssigkeit durch die Struktur gepumpt wird und somit die Wärme schneller abgeleitet werden kann, damit sie sich nicht an einem Punkt aufstaut und dort die Struktur eventuell beschädigt. Und obwohl diese Kühlungsverfahren so gut wie überall problemlos funktionieren, sind sie für die Raumfahrt und vor allem für den Wiedereintritt in die Atmosphäre nicht effektiv genug. Die Hitze vor der Kapsel staut entwickelt sich so schnell und wird so heiß (bis zu 2000°C), dass selbst stahl sofort zu schmelzen beginnt, noch ehe ein passives oder aktives Kühlungsverfahren richtig greifen kann.

Um dies zu umgehen gibt es im Prinzip zwei Möglichkeiten. Erstens die Nutzung eines sehr viel hitzebeständigeren Materials, das die Temperaturen aushalten kann. Und zweitens zu verhindern, dass die extremheiße Luft die Kapsel überhaupt berührt und somit seine Hitzeenergie gar nicht übertragen kann.

Für die erste Möglichkeit, der sogenannten heat absorbtion, wurden vor allem für das Amerikanische Space Shuttle Programm spezielle Materialien entwickelt. Sie nehmen die Hitze beständig immer und immer weiter auf und können viel mehr Hitze aushalten, als herkömmliche Materialien. Das Problem mit diesem Materialien ist allerdings, dass sie meistens strukturell nicht so stabil wie etwa Stahl sind. Bei den hohen Geschwindigkeiten, mit denen die Kapsel oder das Space Shuttle unterwegs ist, können bereits Regentropfen ausreichen um das Hitzeschild zu beschädigen und somit nutzlos zu machen. Denn es langt, wenn nur an einer einzigen kleinen Stelle die Hitze das Schild durchdringt um die dahinterliegende Struktur zu zerstören.

Bei der zweite Möglichkeit, dem sogenannte ablative cooling, wird im gegensatz zu den anderen Techniken darauf gesetzt, dass das Hitzeschild im verlaufe der Landung zerstört wird. Ziel dieses verfahrens ist es, die Luft die sich vor der Kapsel erhitzt von der eigentlichen Struktur fern zu halten. Hierfür wird das Material des ablativen Hitzeschildes kontrolliert abgebrannt um eine Gasschicht zwischen der Heißen Luft und der Kapsel zu bilden. Diese Gasschicht, welche sich aus den verbrennungsgasen der Hitzeschildes zusammensetzt ist zwar auch sehr heiß, allerdings nicht so extrem Heiß, wie die Luft, weshalb viel besser mit dieser Hitze umgegangen werden kann. Die große Herausforderung des ablativen Hitzeschildes ist es natürlich, überall gleichmäßig ein entsprechenden Gaspuffer aufzubauen, denn sonst wird es wieder nutzlos.

Natürlich lassen sich alle oben genannten verfahren gemeinsam verwenden. Dies erhöht zwar die Sicherheit, weil mehrere Schichten die potentielle Hitze abfangen können, aber macht die Kapsel auch wieder schwerer, was mit deutlich höheren Kosten verbunden ist.

Kommt man am Ende heil durch die Atmosphäre, bleibt für das letzte Stückchen meist der altbewährte Fallschirm um sanft auf wieder auf der Erde anzukommen.


Personenerkennung und Personenidentifizierung EDV-NR: 143307a zu Hören bei Prof. Walter Kriha

Rafael Janetzko, Matrikel-Nr.: 40190

Die Anwendungsgebiete der Personenerkennung und Personenidentifizierung wachsen und werden immer präziser, daher gilt die Personenerkennung und Personenidentifizierung im Bereich der Sicherheit zunehmend als essentiell notwendig und ist fast überall vertreten. Heutzutage entsperren die meisten Leute ihr Smartphone mit biometrischen Daten oder überwachen ihr Eigentum mittels Kamerasystemen, die immer ausgereifter und günstiger werden. Doch Systeme zur Personenerkennung und Personenidentifizierung werden auch im öffentlichen Bereich ausgebaut um beispielsweise die Sicherheit zu erhöhen oder für politische Zwecke. Menschen, die einem solchen System begegnen, machen sich oft keine Gedanken über die Datenverarbeitung, da dies mittlerweile zum Alltag gehört. Neben den Vorteilen der Technik bringt sie allerdings auch Nachteile mit sich.

1. Einleitung

Personenerkennung und Personenidentifizierung sollten unterschieden werden. Von Personenerkennung wird gesprochen, wenn anhand von Daten erkannt werden kann, dass sich eine Person in einem Bereich aufhält. Wenn die Daten jedoch einer Identität zugeordnet werden können, wird von Personenidentifizierung gesprochen. Personenidentifizierung ist somit deutlich präziser und nützlicher. Sie findet meist anhand von biometrischen Daten statt. Die gängigsten Techniken dazu sind die Gesichtserkennung mittels Kamerasystemen, einen Fingerabdruck-, Iris- oder Venenscan. Aber auch indirekte Daten, wie eine Adresse, ein QR-Code oder eine Internetverlauf, können zur Personenidentifizierung führen.[7]

2. Aufstieg der Technik

Marktführende Länder mit dem größten Einsatz der Personenidentifizierung sind China und die USA. So hat allein das Utah Data Center der USA eine geschätzte Speicherkapazität für Personenidentifizierung zwischen 1 Yottabyte und 5 Zettabyte. Auf die Weltbevölkerung zurückgerechnet entspräche dies einem Datenvolumen zwischen 1,4 Megabyte und 140 Gigabyte pro Person an Daten, welche gespeichert werden können.
Dass China diese Technik sehr intensiv nutzt ist deutlich, da sich im Jahr 2020 bereits 626 Millionen Überwachungskameras allein in China befinden. Das entspricht drei Einwohner pro Kamera. Die Stadt mit der meistgenutzten Personenidentifizierung ist Shenzhen. Hier befinden sich im Schnitt 60 Kameras auf 500 Meter Weg. Die Kameratechnik ist vor allem so beliebt, da kein aktiver Kontakt zum System notwendig ist. Im Gegensatz dazu benötigt ein Fingerabdrucksensor eine aktive Handlung. Der Durchbruch der Personenidentifizierung durch Kameratechnik fand mit der Künstlichen Intelligenz (KI) statt, als die KI AlphaGo der USA China im Nationalsport GO geschlagen hat. Aufgrund dieses Ereignisses hat Staatschef Xi Jinping KI zur Steuerstrategie auserkoren. Seither gibt es 1200 Startups allein in Peking, darunter auch SenseTime, das teuerste Startup der Welt mit einem heutigen Marktwert von rund drei Milliarden Euro. SenseTime entwickelt eine Gesichtserkennungssoftware, die zur Personenidentifizierung innerhalb der Bevölkerung dient, welche bereits so ausgereift ist, dass sie Personen besser erkennt als Menschen. KI kann bei der Analyse der Daten helfen, sodass selbst aus verpixelten Bildern das Original ausreichend gut wiederhergestellt werden kann.[1,7,9]

Bild 1: Rekonstruktion von Gesichtern einer verpixelten Aufnahme [1]

3. Akzeptanz und Alltag

Damit die Personenidentifizierung akzeptiert wird und an Vertrauen gewinnt, wird die Bequemlichkeit der Menschen, die Angst oder das Streben nach Sicherheit genutzt. Um den Einwohnern das System näher zu bringen gibt es in China den Haidan-Park in Peking, ein intelligenter Stadtpark, indem es unter anderem möglich ist mittels Gesichtserkennung in Einrichtungen und Verkehrsmitteln zu zahlen, Schließfächer zu bedienen und sich im Pavillon ein Lied zu wünschen. Hierfür muss lediglich eine Anwendung auf dem persönlichen Smartphone installiert und eingerichtet werden. Aber auch im Alltag Chinas ist das System mittlerweile angekommen. Zum Zugang zur Arbeit oder zur Identifizierung und zum Bezahlen auf der Straße wird kein Ausweis und keine Kreditkarte benötigt, ein Blick in die Kamera reicht. Aber auch in der Schule können Eltern und Lehrer prüfen, ob ihre Kinder im Unterricht aufpassen, indem das System Handlungen der Schüler erkennt, analysiert und rückmeldet.

Des Weiteren nutzt die Regierung das System zur Verfolgung von Kriminalität, der Kontrolle des Internets vor Missbrauch und unerwünschten Inhalten und zur Verkehrssteuerung- und sicherheit, indem Fehlverhalten direkt bestraft wird. Weitere Einsatzgebiete sind die gerechte Ressourcenverteilung und die Abschaffung der Armut durch Erziehung mittels eines gesellschaftlichen Punktesystems. [2,6,10]

Bild 2: Verkehrsüberwachung in China mittels automatisierter Personen und Objekterkennung[8]

4. Das Punktesystem

Das Punktesystem basiert auf folgendem Gedanken: Wer sich gut verhält, hat nichts zu befürchten und kann davon sogar profitieren, wer sich schlecht verhält wird bestraft. Jeder Bürger hat zu Beginn 1000 Punkte. Wenn dieser sich gut verhält und der Allgemeinheit hilft kann er sich Punkte dazu verdienen, wenn er sich schlecht verhält oder eine nicht akzeptierte Meinung gegenüber einer staatlichen Institution hat, verliert er Punkte. Jeder Bürger kann so maximal 1300 Punkte erreichen und minimal 600 Punkte besitzen. Diese Punkte können entscheidend sein zur Vergabe von Arbeits- und Studienplätzen, der Kredit- und Kontoverwaltung, dem Erlass von Kautionen, zur Reiseerlaubnis oder Zugang in öffentliche Einrichtungen. Wer einen schlechten Punktestand hat, hat es schwerer und dies kann dazu führen, dass er aus der Allgemeinheit ausgegrenzt wird. Außerdem hilft ein derartiges Punktesystem bei der Vermeidung von sozialen Unruhen, kann aber auch dazu führen, dass das System politisch missbraucht wird, indem bestimmte Gruppen und Minderheiten anhand einer Statistik verfolgt werden. Zudem gibt es Forschungen in den USA und China, welche behaupten potenziell kriminelles Verhalten anhand der Gesichtszüge erkennen zu können. [3,11,4,5,8.9,16]

China Sozial Credit System
Bild 3: Vereinfachte Darstellung des Punktesystems in China[16]

5. Fälschungen und Missbrauch

Heutzutage ist es kaum möglich Bildern einer Aufnahme zu trauen. Mittels Deep Fake ist es mittlerweile möglich Aufnahmen glaubhaft zu fälschen, sodass jemand in einem Video Dinge sagt, die er in Wirklichkeit nie gesagt hat oder Dinge macht, die er nie getan hat. Menschen kann so Verhalten unterstellen werden, welches nie stattfand um sie beispielsweise falsch zu verurteilen oder politisch zu beseitigen.
Ebenso kann es zu einem erhöhten psychologischen Leistungsdruck führen und den Menschen so gesundheitlich schaden. Zudem ist nicht bekannt welche Auswirkungen ein Hackerangriff auf ein solches System hat, da kaum Transparenz vorhanden ist. Es kann jedoch zum Datenklau, Datenfälschung oder Manipulation der Identitätszuweisung führen. Diese fehlende Transparenz bietet kaum Einblick in die automatisierte Datenverarbeitung, welche fehlerhaft sein kann.[14,15]

6. Ist ein solches System in der westlichen Welt möglich?

Dass ein solches System politisch in der westlichen Welt ebenso genutzt und gefördert wird, ist seit Veröffentlichung der NSA-Akten durch Edward Snowden und die Stasi-Unterlagen in Deutschland bekannt. Die Erhöhung der Sicherheit gilt dabei als Legitimierung für ein solches System. Zum Beispiel wird das Virus COVID-19 dazu ausgenutzt, die Personenerkennung und das Filmen von Menschen, mittels eines Social Distancing Detectors, zu legitimieren oder Menschen zum bargeldlosen Zahlen zu bewegen. Diese Systeme werden zudem immer komfortabler gemacht, damit sie von mehr Menschen genutzt werden. Des Weiteren wird versucht Barzahlungen bei hohen Beträgen zu verbieten und große Geldscheine, wie den 500€ Schein, abzuschaffen, um den Geldfluss besser identifizieren zu können. Zudem gibt es Systeme, wie die Black Box Schufa, welche anhand personenbezogener Daten eine undurchsichtige Risikobewertung erstellt. So können Menschen benachteiligt werden, auch wenn sie stets ihre Rechnungen bezahlt haben. Stattdessen können Alter, Geschlecht, sowie Wohnort entscheidend sein. Ist beispielsweise jemand männlich, jung und lebt in einer wohlhabenden Gegend, so hat er höhere Chancen auf einen Vertrag oder einen Bankkredit. [12,13,17,18,19]

Bild 4: Social Distancing Detector in einer Fußgängerzone[17]

7. Fazit.

Personenidentifizierung kann unter richtiger Verwendung positiv genutzt werden. Durch fehlende Transparenz der Datengrundlage eines solchen Systems gibt es keine Sicherheitsgarantie, da Ton und Bild glaubhaft verändert und missbraucht werden kann. Demnach sollte das Ergebnis stets hinterfragt werden und die Auswertung der Daten transparent erfolgen, denn Personen ohne Fachwissen erwarten gegenwärtig eine derartige Fälschung nicht. Daten über eine Person zu haben bedeutet auch Macht über diese Person zu haben. Das Leben der Menschen durch Datenmissbrauch zu ihrem Nachteil verändert werden. Googles KI-Forscher Ian Goodfellow sagte dazu: “Es ist ein historischer Glücksfall, dass sich die Menschheit in den letzten Jahrzehnten weitgehend auf Videos verlassen konnte, um sicherzustellen, dass etwas tatsächlich passiert ist.” [20]


[1]​ nn-hast-du-ein-problem
[2]​ hnt-in-china-id7593308.htm
[7] a-laengst-normalitaet-li.37733
[9]​ aat-wird.html
[10]​ ng-1805-134465.html

Behind the scenes of modern operating systems — Security through isolation (Part 1)

In recent years, since the Internet has become available to almost anyone, application and runtime security is important more than ever. Be it an (unknown) application you download and run from the Internet or some server application you expose to the Internet, it’s almost certainly a bad idea to run apps without any security restrictions applied:
Continue reading

System Theory and an Introduction to Complexity

This article gives an introduction to some important aspects of system theory and system analysis. We present some frameworks and toolsets used for system analysis and summarize some key points of these tools. The article aims to show some of the complexity behind system analysis and why there often is no simple solution. It then follows up with some (not so positive) real-world examples to show what can happen when one does not fully understand the complexity of systems and the causal relations within them.

by Paul Fauth-Mayer and Alexander Merker