- Aufgabenstellung und Beschreibung
- Architektur
- Setup
3.1 Blockchain
3.2 Smart Contract
3.3 App
3.4 Raspberry Pi - Beschreibung der Funktionalität
4.1 Blockchain
4.2 Smart Contract
4.2.1 Speicherung der Daten
4.2.2 Modifier
4.2.3 Funktionen des Smart Contract
4.3 Image-Server
4.4 App
4.5 Raspberry Pi
4.5.1 Allgemein
4.5.2 Regestrieren
4.5.3 QR-Lookup - Offene Punkte
- Bisherige Verantwortliche
Mit “ChainCar” soll eine dezentrale Plattform zum Mieten & Vermieten von Automobilen entstehen. Ziel ist die dezentrale Abwicklung der Mietvorgänge sowie der Zugriffskontrolle auf die Fahrzeuge.
Ein Fahrzeugbesitzer kann sich über die mobile App der Plattform registrieren und sein Fahrzeug zur Miete anmelden. Dazu gibt er die erforderlichen Daten im Fahrzeug an (Raspberry), und das Fahrzeug meldet sich dann selbstständig an der Blockchain an. Über einen SmartContract wird das Fahrzeug in der Blockchain persistiert und zur Miete verfügbar gemacht. Kunden können sich nun ebenfalls über die App registrieren (mit ihrer Wallet-Adresse) und verfügbare Fahrzeuge (in einer Liste, sortiert nach Nähe) einsehen.
Möchte der Kunde ein verfügbares Fahrzeug mieten, wird eine Transaktion ausgelöst. Ein SmartContract schreibt den Beginn der Transaktion sowie die Mietkonditionen (Preis, Leistungen, …) in die Blockchain, erhebt die Kosten für die Miete im Voraus und registriert den Kunden als legitimen Nutzer des Fahrzeuges. Der Kunde kann das Fahrzeug nun entsperren (siehe IoT-Team) und fahren. Soll der Mietvorgang beendet werden, wird wieder der SmartContract kontaktiert, welcher dem Mieter abschließend die Nutzungsrechte am Fahrzeug wieder entzieht.
Die Kosten können entweder dem Auto auf das entsprechende Wallet - oder dem Vermieter direkt überwiesen werden.
Die Architektur besteht hauptsächlich aus den folgenden 4 Komponenten:
- Car: Das Auto speichert seine Daten und verwaltet die Zutrittskontrolle. Es überprüft, wer ein legitimer Nutzer ist und Zugang zum Fahrzeug enthält.
- Blockchain: Die Blockchain verwaltet alle Transaktionen, Mietvorgänge und Nutzer.
- App: Über die App können Nutzer sich registrieren und Autos mieten/vermieten. Sie dient gleichzeitig als digitaler Autoschlüssel.
- Backend: Das Backend dient rein als Image-Server, um die Bilder der Fahrzeuge zu speichern, um die teure Speicherung in der Blockchain zu umgehen.
Die einzelnen Komponenten werden nachfolgend in Funktion und Setup erläutert.
Im Folgenden wird das Setup für die Carchain beschrieben. Um ein funktionierendes Setup zu erstellen müssen alle Komponenten provisioniert werden.
Empfohlene Reihenfolge beim bereitstellen:
- Blockchain
- Smart Contract
- Datenbank
- Raspberry Pi
- App installieren
Um die Daten der Carchain in einem Smart Contract speichern zu können wird zu allererst eine Blockchain benötigt auf der der Smart Contract deployed werden kann.
Für die Entwicklung wird dazu Ganache genutzt. Es ist egal ob dabei die Desktop Variante oder Kommandozeilenvariante (Ganache-cli) genutzt wird.
Um das gleiche Setup zu bekommen wie bisher genutzt wurde und damit richtige Testeinstellungen zu bekommen muss Ganache installiert werden.
Zur Installation von Ganache Desktop: https://www.trufflesuite.com/ganache
Zur Installation von Ganache-cli: https://github.com/trufflesuite/ganache-cli
Wie man die Einstellungen ändert, unterscheidet sich zwischen der CLI und der Desktop Variante. Im Folgenden wird sich auf die CLI Variante beschränkt, da diese am besten einzusetzten ist wenn man nicht nur an der Blockchain entwickeln will sondern auch die Verbindung zu der App oder dem Raspberry Pi testen möchte.
Einstellungen zum Start der Blockchain:
ganache-cli -m "dragon canoe knife need marine business arctic honey make layer company solar" -h "" -p -e 10000 &
Die Message die hier Ganache mitgegeben wird bestimmt welche Adressen die Wallets, die schon vornherein generiert und zur Verfügung gestellt werden, haben. Voreingestellt ist für die Entwicklung 10.000 Ether, die jede Wallet von vornherein bekommt. Sobald der Command ausgeführt wurde gibt es nun eine Blockchian, die für die weitere Entwicklung genutzt werden kann.
Um mit den Smart Contracts arbeiten zu können sind einige Installationen nötig.
Diese werden mit npm (dem Node Package Manager) installiert. Zur Installation:
https://www.npmjs.com/get-npm
Nach der Isntallation von npm muss um alle Dependencys des Smart Contracts aufzulösen folgender Befehl im Blockchain Ordner ausgeführt werden:
npm install
Das Kompilieren, Testen und das Deployen des Smart Contracts geschieht nun mit Truffle. Zu aller erst muss dazu im Ordner /Blockchain/ethereum/ die Datei truffle-config.js angepasst werden. Dazu kann ein Server erstellt werden. Ein Beispiel hierfür ist hier zu sehen:
Neben Host und Port gibt es gas. Gas dient dazu zu bestimmen wieviel maximal an Gas ausgegeben werden darf um den Contract zu deployen. Network_id ist auch speziell für die Blockchain, falls es unterschiedlcihe Blockchains auf der gleichen IP gibt. Nachdem die Einstellungen getätigt sind kann nun der Contract compiled und deployed werden. Dazu dient das Kommando:
truffle migrate --network
Der Network-Name ist dabei der Name, der in der truffle-config.js in den networks eingetragen wurde. Weitere Dokumentation zu dem Kommando truffle migrate ist unter
https://www.trufflesuite.com/docs/truffle/getting-started/running-migrations
zu finden.
Derzeit wird die App als APK-Paket angeboten und muss manuell installiert werden. Eine Distribution über die gängigen AppStores wie bspw. GooglePlay ist natürlich angedacht, sobald eine Veröffentlichung denkbar ist.
Um die App zu installieren, muss mittels einem Datei-Manager die APK-Datei ausgewählt werden. In aktuelleren Android Versionen muss zunächst in den Einstellungen die Sicherheitsrichtlinie “Apps aus Fremdquellen installieren” aktiviert werden. Dann kann die App mit einem Klick auf die Datei installiert und ausgeführt werden.
Zum aktuellen Zeitpunkt wird die entsprechende Wallet-Adresse noch vorgegeben und vom Server/Blockchain abgerufen, sodass in diesem Stadium die weitere Funktionalität getestet werden kann. Später ist angedacht, beim ersten Start der App ein Wallet-File zu generieren und mit den Credentials des Users zu sichern. Dieses Wallet kann dann aufgeladen werden.
Beim starten der App wird automatisch der aktuelle Standort abgerufen (sofern Berechtigung erteilt) und die verfügbaren Autos im Umkreis geladen und angezeigt [aktuell Demodaten].
Raspberry Pi
Um die Funktionalitäten des Raspberry Pi's im Gesamtkontext des Projekts nutzen zu können muss zunächst eine passende Entwicklungsumgebung aufgebaut werden. Hierfür ist es notwendig an das Camera Serial Interface des Pi's eine Kamera anzuschließen und diese in den Einstellungen zu aktivieren (sudo raspi-config --> Enable Camera).
Desweiteren sind für den produktiven Betrieb 3 LEDs und 2 Buttons notwendig. Diese werden über die GPIO-Pins des Raspberry Pi's angesteuert werden. Dabei ist folgende Zuordnung zwischen den Pins und der Hardware zu treffen:
- Pin 17: Regestrieren Button (Blau)
- Pin 18: QR-Lookup Button (Gelb)
- Pin 19: Rote LED
- Pin 20: Gelbe LED
- Pin 21: Grüne LED
Die rote LED gibt im Projektkontext an, dass das Auto gesperrt ist, die gelbe LED symbolisiert das gerade intern eine Verarbeitung geschieht und die grüne LED steht entsprechend dafür, dass das Auto geunlocked ist. Die beiden Buttons werden dafür verwendet die beiden Hauptfunktionalitäten auszulösen: Der blaue um das Auto an der Blockchain und dem Datenbankserver anzulegen und der gelbe Button um einen QR-Lookup durchzuführen und das Auto gegebenenfalls anschließend zu entsperren.
Innerhalb unserer Entwicklungsumgebung wurden die genannten Komponenten auf einer Steckplatine platziert und entsprechend verkabelt. Die Steckplatine wurde über einen T-Cobbler mit den Pins des Raspberry Pis verbunden. Die notwendigen Hintergrundinformationen um die Verkabelung durchzuführen wurden mit Hilfe der Seite
https://www.w3schools.com/nodejs/nodejs_raspberrypi_gpio_intro.asp
erarbeitet.
Der Zugriff auf den Raspberry Pi in diesem Projekt geschieht über die Domain "carchain-pi.dnsuser.de". Die entsprechenden Stellen im Quellcode sind entsprechend bei einer geänderten Umsetzung zu ersetzen. Der Raspberry Pi befand sich innerhalb der Entwicklungsumgebung in einem lokalen Netz (192.168.178.0/24) eines Routers mit der lokalen IP: 192.168.178.1. An dem Netzwerk-Interface des Raspberry Pis wurde die statischen lokalen IP 192.168.178.42 angelegt. Damit die Domain "carchain-pi.dnsuser.de" stetig auf die sich ändernde öffentliche IP des Routers verweiset, wurde ein DynDNS-Dienst in der Konfiguration des Routers eingerichtet. Damit Anfragen aus dem Internet durch Router auf den Raspberry Pi innerhalb des lokalen Netzes weitergeleitet werden, wurde ein Port-Forwarding eingerichtet (Port: 22, für SSH-Verbindungen, Port 9100: für den "Prometheus-Node-Exporter").
Über die eigentliche Zielsetung des Projekts hinaus wurde im Projektverlauf noch eine Automatisierte-Bereitstellungspipeline mit Ansible erstellt, um neue Raspberry Pis/Autos einfach automatisiert provisionieren zu können und ein Monitoring des Raspberry Pis/Autos mit Prometheus und Grafana eingerichtet. Hierfür ist es notwendig Ansible, Prometheus und Grafana auf einem Server zu installieren. Im Projektkontext wurde der gleiche Server auf dem auch die Blockchain läuft verwendet. Prometheus und Grafana wurden dabei innerhalb von zwei Docker Containern betrieben.
Automatisierte Bereitstellungspipeline
Wie bereits erwähnt wird Ansible für die optional entwickelte automatisierte Bereitstellungspipeline verwendet. Ansible besteht aus drei elementaren Komponenten:
- Eine allgemeinen Konfigurationsdatei, in der wir lediglich den Pfad zu unserem Inventory angegeben haben: https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/ansible_rapi/ansible.cfg
- Ein Inventory, dass alle IPs/Hostnames der Systeme/Autos die orchestriert werden sollen enthält (in dieses wurde der Hostname des Raspberry Pis zusammen mit den Zugangsdaten hinterlegt): https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/ansible_rapi/host.file
- Ein Playbook, dieses enthält eine Menge von Tasks, also Aufgaben die von Ansbile auf der liste von Systemen in dem Inventory durchgeführt werden. Hier kann man deklarativ im yaml format den gewünschten Systemzustand beschreiben.
https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/ansible_rapi/rapi_playbook.yml Unser Playbook enthält dabei folgende Tasks:
- Installieren von Node.Js, NPM und dem Node-Exporter über APT + enable Node-Repository
- Kopieren des privaten SSH-Schlüssels für Zugriff auf Git
- Konfiguration von OpenSSH (durch ssh_config.j2) & ssh-keyscan git.smagcloud.de
- Klonen des Repos ([email protected]:Tachmeton/Carchain.git)
- Installieren der benötigten NPM-Pakete (aus npm-requirements.txt)
- Kopieren des angelegten Unit-Files (durch car_js.service) für automatisches Starten
- Konfiguration von Systemd (car_js.service & node-exporter starten + enablen)
- Ausführen von register_car.js (Registrieren des PIs an der BC + Bild-Upload an DB)
Die von den Tasks verwendeten Hilfs-Dateien sind dabei in einem extra angelegten "Data"-Ordner im Repository vorhanden:
https://github.com/Tachmeton/Carchain/tree/master/RaspberryPi/ansible_rapi/data
Das Playbook kann durch den Befehl "ansible-playbook rapi_playbook.yaml" ausgeführt werden. Ansible provisioniert anschließend den Raspberry Pi automatisiert. Das Ergebnis ist, dass das Entwicklungs-Repository auf den Raspberry Pi gekloned wurde, alle benötigten Abhängigkeiten installiert und das Node.Js Skript, dass die Funktionen "Regestrieren" und "QR-Lookup" bereitstellt, als Systemd-Dienst gestartet wurde. Ebenfalls wird der für das Monitoring benötigte sogenannte "Prometheus-Node-Exporter" installiert und gestartet.
Monitoring
Das optional umgesetzte Monitoring des RaPis mit Prometheus und Grafana wurde erstellt, da es sinnvoll ist ein Monitoring der Autos zu haben, wenn die Anwendung eines Tages produktiv zum Einatz kommen sollte, um Festzzustellen das alles korrekt funktioniert. Hierfür wurde um nicht immer mit einer abstrakten IP zu arbeiten, eine kostenlose ".tk" Domain für unseren Entwicklungs-/Blockchainserver eingerichtet. Angelegt wurde ein DNS-Eintrag der Domain "carchain-server.tk", die auf den Server mit der IP "193.196.54.51" verweist. Die entsprechenden Stellen im Quellcode sind entsprechend bei einer geänderten Umsetzung zu ersetzen.
Prometheus und Grafana selbst betreiben wir über Docker, das wir entsprechend auf dem Server installiert haben. Als Grundlage haben wir die offiziellen Standard-Images von Prometheus und Grafana verwendet. Da die Container an sich zustandslos sind und nach dem Stoppen unverändert vorliegen, haben wir für einen persistenten Speicher 2 Volumes angelegt, einen für Prometheus und einen für Grafana, die entsprechend in die Container gemountet werden. Dies hat denn Sinn dass nach einem Neustart des Servers unsere vorherigen gespeicherten Monitoring-Daten weiterhin verfügbar sind. Ein eingerichteter Cronjob sorgt dafür nach einem Neustart des Servers die beiden Container automatisch wieder gestartet werden.
Prometheus bestitzt eine Time Series Database, in die per HTTP gesammelte Metriken geschrieben werden. Die Konfiguration geschieht über eine YAML-Datei, die mit in den Container gemountet wird:
https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/monitoring_rapi/prometheus_config_carchain.yaml
In der Datei haben wir ein Scrape-Intervall von 15 Sekunden festgelegt, d.h. alle 15 Sekunden führt Prometheus eine HTTP-Anfrage zu dem Raspberry Pi aus, in unserem Fall über die Domain "carchain-pi.dnsuser.de".
Damit auf dem Raspberry Pi überhaupt an einem HTTP-Endpunkt Metriken bereitgestellt werden, kommt unter Prometheus ein sogennanter Exporter zum Einsatz der hierfür verantwortlich ist. Wir haben uns für den Einsatz des offiziell von Prometheus bereitgestellten Node-Exporter entschieden. Der Node-Exporter wurde in der automatisierten Bereitstellungspipeline zuvor installiert und gestartet. Der Node-Exporter ist in der Lage allgemeine HW und OS Metriken auf dem TCP port 9100 bereitzustellen.
Damit wir auf die von Prometheus gesammelten und gespeicherten Daten übersichtlich zugreifen können verwenden wir Grafana. Mit Grafana lassen sich einfach Dashboards anlegen. Die Dashboards werden dabei im JSON-Format beschrieben, für den Node-Exporter haben wir dann ein vorgefertigtes Dashboard genommen und nur geringfügig angepasst:
https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/monitoring_rapi/grafana_dashboard_carchain.json
Das Dashboard ist in unserem Fall unter der Domain unserers Entwicklungsserveers auf Port 3000 erreichbar. Auch lassen sich in Grafana Alerts festlegen, so das wir automatisch benachrichtigt werden sobald z.B. ein Raspi ausfällt oder die System-Werte so aussehen das er in Zukunft ausfallen könnte.
Die Blockchain an sich dient als Hub für die Smart Contracts. Auf geschieht alles, was mit der Verwaltung der Mietdaten. Des Weiteren läuft über die Blockchain die Bezahlung um Autos zu mieten. Deswegen ist es im späteren Sinnvoll die Contracts auf eine Public Blockchain zu deployen, damit die Bezahlung auch wirklich einen Impakt hat. Aktuell ist der Smart Contract der weiter unten beschrieben wird nur auf der Development Blockchain Ganache getestet.
Der Smart Contract ist im Ordner Blockchain/ethereum in der Datei carchain.sol implementiert. Als Smart Contract Programmiersprahce wurde Solidity benutzt.
Die wichtigste Aufgabe, die der Smart Contract übernimmt, ist das speichern, der Daten über die zu vermietenden Autos. Diese sind in einer Map gespeichert, die bei Erstellung des Contracts aufgebaut wird. Die Map bildet die Wallet Adressen der Autos auf eine Car-Struktur ab.
In selbiger Car Struktur sind gespeichert:
- Daten über den Owner
- Daten über den aktuellen Mietstatus
- die Zeit wie lange das Auto aktuell gemietet ist
- der insgesammt bekommende Ether
- der normale Standort des Autos
- Daten über das Auto an sich
- Konditionen zum Mieten des Autos
Solidity bietet die Möglichkeit Modifier, mithilfe von requires zu defineiren. Modifier dienen in diesem Projekt dazu, vor dem richtigen Start einer Funktion zu checken ob der Aufrufer dazu berechtigt ist selbige aufzurufen und ob alle Vorraussetzungen für einen kompletten Durchlauf der Funktion gegeben ist. Bisher implementierte Modifier:
| Name des Modifiers | Parameter | Funktion |
|---|---|---|
| knownCar | Identifier/ Walletadresse des Autos | Festellen ob das Auto welches die Funktion betrifft überhaupt exisitiert |
| onlyOwner | Identifier/ Walletadresse des Autos Identifier/ Walletadresse des vorgeblichen Owners |
Feststellen ob die übergebene Wallet Adresse Owner des übergebenen Autos ist |
| isLeased | Identifier/ Walletadresse des Autos | Befindet sich das Auto schon im gemieteten Zustand |
| isLeasedBy | Identifier/ Walletadresse des Autos Identifier/ Walletadresse des Leasers |
Ist als Leaser die Walletadresse des vorgeblichen Mieters eingetragen |
| carFree | Identifier/ Walletadresse des Autos | Ist das Auto aktuell frei |
Bei allen Methoden, wo ein Auto mit beeinflusst ist, sollte die Funktion knownCar vorher aufgerufen werden um während der Ausführung der Funktion nicht auf Fehler zu stoßen. Auch die Restriktion auf Adressen die nur bestimmt Funktionen ausführen dürfen sit wichtig. Hierfür sollte der Modifier onlyOwner verwendet werden. Man köannte noch andenken, dass ein Auto mehrere Owner hat. Dies ist aktuell aebr nciht implementiert. Die Checks ob ein Auto schon geleased ist oder von wem geleased wurde oder es frei ist, werden natürlich dann eingesetzt wenn es um den akuten Mietvorgang geht.
Über das Speichern der Autodaten hinaus bietet der Smart Contract die Möglichkeit die Daten zu verändern. Dazu dienen verschiedene Arten von Funktionen.
Die implementierten public Funktionen sind im Folgenden aufgelistet mit ihrer möglichen Einsatzfunktion:
| Name der Funktion | Übergabeparameter | Modifier | View | Rückgabewerte | Payable | Einsatzgebiet |
|---|---|---|---|---|---|---|
| getter zugehörig zum Attribut des Autos | Identifier/ Walletadresse des Autos | knownCar | Ja | das Attribut im getter | Nein | App |
| addCar | Alle Daten zugehörig zum Auto | ID ist noch nicht genutzt | Nein | - | Nein | App |
| removeCar | Identifier/ Walletadresse des Autos | knownCar, onlyOwner, carFree | Nein | - | Nein | App |
| rentCar | Identifier/ Walletadresse des Autos | knownCar, carFree | Nein | - | Ja | App |
| mayRent | Identifier/ Walletadresse des Autos | knownCar | Ja | Boolean Value | Nein | App |
| isLegalLeaser | Identifier/ Walletadresse des Autos, Identifier/ Walletadresse des Mieters | knownCar, isLeased. isLeasedBy | Ja | Boolean Value | Nein | Raspberry Pi |
| returnCarToCarpool | Identifier/ Walletadresse des Autos | knownCar, isLeased. isLeasedBy | Ja | - | Nein | App |
| getAvailableVehicles | - | - | Ja | Array aus Wallet Adressen zugehörig zu den freien Autos | Nein | App |
Will man die Funktionen einmal ausprobieren oder einen kompletten Durchlauf sehen und ob dieser funktioniert. Eignet sich neben Unit Tests, die noch zu implementieren sind die Dateien carchain_interact.js und carchain_interact2.js im Ordner /Blockchain/ethereum. Die erste carchain_interact Datei legt eine Auto an, was in Folge dessen gemietet wird. Darufhin werden einzelne Attribute des Autos abgefragt und das Auto zum Schluss wieder gelöscht. In der zweiten Datei wird ein Auto angelegt, woraufhin alle verfügbaren Auots angefragt weren und danach die Blockchain wieder resettet wird. Beide Dateien sind dazu gedacht mit der Blockchian rumspielen zu können und Funktionen mit der Hilfe von Java Script zu testen und ein Gfefühl für die Blockchian zu bekommen.
Carchain soll in der Lage sein Bilder für Autos speichern und abrufen zu können. Da das Speichern und Abfragen von Bildern an der Blockchain sowohl das Aufkommen von Transaktionen so wie den Speicherplatz sehr stark belasten würde, wurde diese Funktion ausgelagert. Es wurde daher ein REST-Backend zur Speicherung und Abfrage von Bildern implementiert. Das Backend bietet fünf Schnittstellen beziehungsweise Endpunkte an, die für die Speicherung und Abfrage der Bilder genutzt werden können. Das Backend wurde in NodeJs implementiert und hat eine Anbindung an eine Postgres Datenbank, in der die Bilder verwaltet werden. Die Bilder werden beim Empfang in Base64 umkodiert und in der Datenbank als Text gespeichert. Wenn ein Bild hochgeladen wird, wird dies für ein spezielles Auto hochgeladen. Daher muss im Voraus das Auto in der Datenbank angelegt worden sein, da ansonsten das Bild mit keinem Auto verknüpft werden kann. Es werden in dem Backend zwei (HTTP-) PUT, zwei GET und eine DELETE Funktion bereitgestellt.
Diese Funktionen sind hier nun kurz mit Übergabeparameter und Return-Values angegeben:
Erwartet application/json mit carid
{
"carid": "string"
}Returns:
{
"success": 1,
"error": false,
"msg": "Message received-insert succeed"
}Erwartet application/json mit carid (string) und einem Bild (File)
{
"carid": "string",
"carimage": "File"
}Returns:
{
"success": 0,
"error": true,
"msg": "Message received-insert succeed",
"imageid": 2
}Erwartet application/json mit carid (string) und einem Bild (File)
{
"carid": "string",
"carimage": "File"
}Returns:
{
"success": 0,
"error": true,
"msg": "Message received-insert succeed",
"imageid": 2
}Erwartet carid in URL à 193.196.54.51:3005/getImages/String (Car Id) Returns:
{
"success": 1,
"error": false,
"msg": "Message received with id:TÜ-LF-308",
"imagejson": [
{"id":2,"image":"base64EncodedImage"},
{"id":3,"image":"base64EncodedImage"},…
]
}Erwartet carid in URL à 193.196.54.51:3005/getImages/String (Car Id) Returns:
{
"success": 1,
"error": false,
"msg": "Car and all images deleted"
}Das Backend wird wie bereits erwähnt genutzt, um die Bilder für die Autos zu speichern. Es wird hier nun der Vorgang schematisch dargestellt.
Beim Hinzufügen eines Bildes wird dieses, mit der ID, welche ein Auto repräsentiert, an den Server geschickt. Der Server prüft mit einer Datenbank Abfrage, ob die ID in der Datenbank enthalten ist. Ist diese ID enthalten, wird das Bild, nachdem es in Base64 umkodiert wurde, in der Datenbank gespeichert und mit der ID verknüpft. Die ID des Bildes wird anschließend in der http Repsonse mitgeschickt. Man kann mehrere Bilder einem Auto hinzufügen. Diese Bilder können alle gesammelt abgefragt werden. Hierzu muss man nur den entsprechenden Befehl mit der Auto Id aufrufen. Natürlich muss man zu Beginn die Auto Id anlegen. Es ist auch möglich, die Bilder einzeln anhand ihrer ID abzufragen. Das Backend wurde mithilfe von nodejs entwickelt. Das nodejs Programm wird auf dem Server aufgesetzt und die genutzten Packages installiert. Dies wären:
- express: Starten der Server App
- bodyParser: Bearbeitung des http Body
- http: Server Funktion
- multer: Für File upload
- fs: Für Filesystem
- crypto-js: Für die Hashfunktion des Tokens
Die Server Applikation wird auf dem Port 3005 gestartet.
Die App besitzt die drei Hauptreiter “Entdecken/Durchsuchen”, “Digitale Schlüssel/akt. Mieten” und “Einstellungen”.
Im “Entdecken”-Reiter können die verfügbaren Fahrzeuge eingesehen und gefiltert werden. Standardmäßig ist die Liste nach Entfernung des Autos in aufsteigender Reihenfolge sortiert. Mit einem Klick auf das Auto können Detail-Informationen angezeigt werden und die gewünschte Mietdauer eingestellt werden. Mit einem Klick auf “Mieten” wird eine Miete initiiert - sofern genug Guthaben im Wallet verfügbar ist.
Das gemietete Fahrzeug wird dann im Reiter “Digitale Schlüssel / aktive Mieten” angezeigt. Hier kann eingesehen werden, wie weit das Auto entfernt ist und wie lange die Miete noch läuft. Ein Klick auf das Auto generiert den digitalen Autoschlüssel - einen QR-Code - der Informationen enthält, mit der das Auto (Raspberry Pi) den Mieter identifizieren kann und überprüfen, ob der Nutzer zum Zutritt berechtigt ist.
Im Einstellungen-Reiter sollen künftig das Profil und Wallet verwaltet werden können.
Im Folgenden werden die beiden wesentlichen im Pflichtenheft geforderten und in Node.Js umgesetzten Funktionen (Regestrieren + QR-Lookup) aus der Datei "car.js" stichpunktartig beschrieben:
https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/car.js
Für den Betrieb des Skripts müssen im Voraus über den Node package manager folgende Pakete installiert werden (werden aber eigentlich bereits automatisiert in der Bereitstellungs-Pipeline installiert):
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Das OnOff-Modul für das Steuern der GPIO-Pins verwendet. Es wird ein Event ausgelöst sobald einer der beiden Buttons gedrückt wird, wenn dies der Fall ist wird die entsprechende dahinterliegende Funktion ausgelöst. Mit Blockchain wird über die eingebundene Web3-Schnittstelle kommuniziert. Zudem läuft eine dauerhaft im Intervall von 15 Sekunden ausgeführte Schleife im Hintergrund, diese überprüft an der Blockchain über die eingebundene “isLegalLeaser” Smart-Contract Funktion, ob der zuletzt hinterlegte Mieter eines Autos weiterhin der Mieter ist. Dies hat den Sinn, dass ein ausgeliehenes Auto nicht unbegrenzt genutzt werden kann und sich spätestens 15 Sekunden nach dem ausgelaufenen Mietvertrag wieder sperrt.
Anmerkung der Inhalt der Funktion wurde ausgelagert, da diese primär innerhalb der automatisierten Bereitstellungspipeline ausgeführt werden sollte:
https://github.com/Tachmeton/Carchain/blob/master/RaspberryPi/ansible_rapi/data/register_car.js
- Bei Knopfdruck: Registrieren (auch realisiert in Bereitstellungs-Pipeline, aber gleiche ausgeführte Funktion)
- Nutzen der Smart-Contract Funktion: “addCar”
- Picture Upload über HTTP-Put mit newman
- register-collection.json für Beschreibung der HTTP-Anfrage
- Bei Knopfdruck: QR-Lookup → Gelbe “In Bearbeitung”-LED
- Aufnahme und speichern eines Fotos mit Pi-Camera-Modul
- Suchen nach QR-Code mit Qrcode-Reader-Modul
- Falls Wallet-Adresse gefunden: Abfragen ob existent an Blockchain (Web3)
- Nutzen der Smart-Contract Funktion: “isLegalLeaser” um zu überprüfen, ob der Nutzer der übergebenen Wallet-Adresse berechtigt ist auf das Auto zuzugreifen
- True: Grüne LED = Offen (+Gelb aus)
- False: Rote LED = Geschlossen (+Gelb aus)
- Web3 Implementierung in der App
- Unit Tests für Smart Contract schreiben
- Smart Contract auf Public Blockchain einsetzen
Blockchain - Tachmeton (Bastian Frewert)
App - Simon Gaugler, Jan Quintus
Datenbank - lfs1991 (Lukas Faiß)
Raspberry Pi - nilsriekers, (Nils Riekers)