Abschlussbericht
===

Akronym: FabAccess
Projekttitel: FabAccess - Förderierte Infrastruktursoftware für FabLabs, Makerspaces und andere offene Werkstätten
Zuwendungsempfänger: Gregor Reitzenstein, Jannis Rieger, Joseph Langosch, Kai Kriegel, Tasso Mulzer GbR
Name des Zuwendungsempfängers: Gregor Reitzenstein, Jannis Rieger, Joseph Langosch, Kai Kriegel, Tasso Mulzer GbR

Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen **01IS20S41** gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.

# Kurze Darstellung der Aufgabenstellung und Motivation
> Was war Deine Motivation?

Wir möchten FabLab, MakerSpaces, usw. (Spaces) ein Tool geben, mit dem der Zugriff auf Maschinen verwaltet werden kann und so mehr Sicherheit in einem solchen Space entsteht.
Weiterhin möchten wir die Zusammenarbeit von Spaces fördern in dem sich Föderationen aufbauen.
> Welches Problem wolltest Du mit Deinem Projekt lösen?

Der Zugriff auf Maschinen an den sich Nutzer:innen verletzten können ist aufwändig und bei solchen Maschinen muss immer sichergestellt werden, dass nur Nutzer:in die eingewiesen sind auch Zugriff auf solche Maschienen haben.

> Wie war die geplante Vorgehensweise zur Problemlösung (auch Angabe der wichtigsten Meilensteine)?

Vor 2 Jahren kam die Idee zu solch einem System, bei der Kommunikation mit anderen Spaces. Dabei ist herausgekommen, dass es vereinzelt anfängliche Lösungen gibt, aber noch keine über den Stand "Works-for-me" hinaus ist.
Darauf hin wurde ein Lastenheft mit den Zielen an ein solches Projekt erstellt, um möglichst viele Anforderungen schon am Anfang eines Projekts vorliegen zu haben.

In der Föderphase sollte dann im erstem Monat die Struktur und die technischen Möglichkeiten erarbeitet werden, sowie in Kombination mit dem zweiten Monat die Proof-of-Concept umgesetzt werden.
Parallel sollte dann im zweiten Monat mit der Arbeit an unserem Backend begonnen werden, da hier weniger Proof-of-Concepts ausstehen.
Für den vierten Monat war ein Alpha-Test unseres Systems in unserem Labor geplant und danach im letzen Monat ein Beta-Test mit anderen Spaces um die Föderation und deren Konzepte zu erproben.

# Beitrag des Projektes zu den Zielen der Förderinitative „Software-Sprint“
> Welche Bezüge gibt es zu den Themenfeldern „Civic Tech“ und „Data Literacy“ des Software Sprints oder zu weiteren gesellschaftlich relevanten Zielen bzw. Lösungsansätzen?

Unsere Software soll den Verwaltungsaufwand in FabLabs, Makerspaces, usw. vereinfachen und auch mit kleinem Personal verwaltbarhalten. Dabei wird auch die Idee eines FabLabs berücksichtigt, nach der jeder Zugriff auf die Resourcen eines Spaces bekommen soll. Wir möchten so für mehr FabLabs sorgen, damit es mehr Orte der Bildung gibt.

# Ausführliche Darstellung der Ergebnisse
> Welche konkreten Ergebnisse hast Du erzielt? Konnten alle Meilensteine erreicht werden?

Wir haben sehr an der technischen Realisierung eines SmartCards-Systems gehangen, mit dem man sicher und Space übergreifend arbeiten kann, dazu haben wir einen Proof-of-Concept erstellt und arbeiten derzeit an der Umsetzung in unser System.
Durch die Corona Pandemie haben wir unseren Alpha-Test und die geplanten Beta-Tests nicht umsetzten können, da der Zugang zu den Räumlichkeiten nicht möglich war. Das hat auch die Umsetzung der Software in die Länge gezogen.
Wir haben zum aktuellen Zeitpunkt eine Pre-Alpha Version unseres Servers, sowie eine grundlegende Version unseres Clients.
Bei den beiden Softwarekomponenten ist sehr viel Arbeitsaufwand in die Strukturierung geflossen, um nach den Rückmeldungen des Alpha-Tests, sowie der Beta-Tests mit möglichst wenig Aufwand den Code anpassen, sowie zukünftige Features einzubauen zu können.
Die Planung der Funktionen und deren Strukturierung liegen auch noch vor und werden nach dem Alpha-Test überarbeitet und veröffentlicht.
Technische Grundlagen für die Föderationsmöglichkeit zwischen Serverinstanzen wurden gelegt, jedoch zeigte sich im Laufe der Entwicklung das verschiedene technische Ansätze evaluiert werden müssen, wodurch sich die vollständige Implementation und Testung der Föderationsmöglichkeit nach hinten verschob.

> Welche zusätzlichen Erkenntnisse hast Du aus der Projektarbeit gewonnen, auch im Hinblick auf die Begleitung durch die Open Knowledge Foundation?

Infrastrukturzentrierte Software die für den Einsatz in Räumlichkeiten gedacht ist, stellte uns ohne Zugriff auf die Infrastruktur und Räumlichkeiten vor ungeplante Probleme, insbesondere bei der Testung und Fehlerbehebung.

# Zielgruppe, Nutzen und mögliche Weiterentwicklungen
> Welcher Nutzen ergibt sich für die Zielgruppe aus den Ergebnissen Deines Projekts?

Durch die große Visibilität die unser Projekt durch die Förderung und auch direkt duch die Internetauftritte des BMBF und Prototypefund erhalten hat, zentriert sich die weitere Entwicklung auf FabAccess, anstatt auf Lösungen einzeler Makerspaces und FabLabs. Dies ist auch insbesondere ein Vorteil, weil durch die Prototypenphase der weitere Entwicklungsaufwand und sinnvolle Entwicklungsansätze besser eingeschätzt werden können.

> Welche weiter-gehenden Effekte ergeben sich aus der Open-Source-Stellung der Ergebnisse?

Die offene Entwicklung des Projektes ermöglicht Space übergreifend an einer gemeinsammen Lösung zuarbeiten. Somit muss nicht jeder Space für sich eine solche Software einwickeln, die dann nur auf die Probleme des jeweiligen Spaces ausgelegt ist. Da alle Spaces ähnliche Probleme haben kann so die Arbeitsleistung auf ein Projekt fokusiert werden, dadruch wird die Stabilität und Sicherheit einer solchen Software erheblich verbessert.
Sollte das Projekt FabAccess von den meisten Spaces benutzt werden können auch Vorschläge an die Industrie herangetragen werden, um so die Verfügbarkeit von kompatiblen Hardware zu erhöhen. Dadurch wird es kleiner, neuen Spaces ermöglicht schnell einen Einstieg in ein sicheren Betrieb finden. Auch die Anbindung neuer Hardware(elektronische Schlossystem, Smarte Steckdosen, usw.) kann so durch Offenlegung der Schnittstellen schneller eingebunden werden und nicht jeder Space muss das für sich alleine entwicklen.

> Gibt es Ideen für die Weiterentwicklung Deiner Lösung und Pläne zu deren Umsetzung?

Der aktuelle Stand des Projektes soll von dem Alpha-Test Phase in die nächsten Phasen getrieben werden. Auch die Föderationsumsetzung wird erfolgen.
Wir haben uns auch mit anderenen Anwendungsmöglichkeiten für unseren Core umgeschaut und sind dahingehend in Gesprächen mit Lastenradverleihvereinen, da diese mit den Möglichkeiten unseres Cores im Prinzip auch verliehen werden können. Weitere Sharing basierte System sind auch möglich, solange ein elektronisch ansteuerbares Schloss verwendet wird oder die auszuleihende Dinge einen Inventaraufkleber besitzten. Dieses Prinzip des Teilens wird dabei durch die Föderationsprinzipen unterstützt.

> Hat die Arbeit in dem Projekt Dich in Deiner persönlichen, fachlichen Weiterentwicklung unterstützt?

Wir hatte die Möglichkeit uns mit der GUI Entwicklung in Xamarin zubeschäftigen, sowie mit der Backend Entwicklung in Rust.
Desweiteren konnten wir Erfahrungen mit den Build- und Veröffentlichungssystem verschiedener Platformen sammeln.

# Kurze Darstellung der Arbeiten, die zu keiner Lösung geführt haben
> Gab es Arbeiten bzw. Lösungsansätze, die nicht weiter verfolgt wurden?

Die Verwendung von Mifare Classic RFID-Karten wurde am Anfang implementiert, jedoch auch wieder früh beendet.
Zudem gab es mehrere Ansätze zur Implementation der Förderation zwischen Serverinstanzen, unter anderem ein Ansatz basierend auf dem IETF-Standardprotokoll DIAMETER.

> Was waren die Hintergründe, und wie bist Du alternativ vorgegangen?

Da Mifare Classic Karten über keinerlei Kopierschutz verfügt wurde stattdessen auf Mifare DESFire Karten umgestellt. Die starke Authentifizierung der Karte erlaubt eine sichere Kommunikation gegenüber einem föderiertem Server.
Die Entwicklungen des Förderationsansätze basierend auf DIAMETER wurden wieder verworfen, da DIAMETER zwar große Vorteile bei zukünftigen Entwicklungen alternativer Server, die mit den vorhandenen Instanzen föderieren können, besitzt, jedoch kamen wir nach einer Kosten-Nutzen-Abwägung zum Schluss das der Aufwand durch Umstellung auf DIAMETER, insbesondere in einer Protypenphase, nicht von den Vorteilen gerechtfertigt war.

# Kurze Angabe von Präsentationsmöglichkeiten für mögliche Nutzer
> Wo können sich Interessenten detailliert über Deine Projektergebnisse informieren (z.B. Webseite, GHitHub, Veröffentlichungen)?

Im Rahmen der Prototypenphase wurde von uns ein Webauftritt erstellt, dieser ist unter der URL https://fab-access.org zu finden.
Zusätzlich verwenden wir die offene Entwicklungsplattform GitLab für unseren Code. Fortschritte und Pläne in der Entwicklung, Anregungen und Probleme andere Parteien können dort unter https://gitlab.com/fabinfra/fabaccess alle eingesehen werden.
Eine weiter Erläuterung der Ziele und den Desingentscheidungen haben wir in einem Vortrag auf dem rC3 in Form eines Vortrags zusammengefasst, zu finden unter https://media.ccc.de/v/rc3-326175-fabaccess.

# Kurze Erläuterung zur Einhaltung der Arbeits- und Kostenplanung
> Gab es im Projektverlauf Ereignisse, die eine Anpassung der Planung erforderlich machten – z.B. Mehr- oder Minderaufwand bei der Bearbeitung von Teilaufgaben?

Da Dokumentation der Mifare DESFire nur mit einem Geheimhaltungsvertrag und nur an Firmenkunden ausgegeben wird, konnten wir nur auf von dritten erstellte, oft unvollständige Unterlagen und Beschreibungen der DESFire Karten und des verwendeten Protokolls zugreifen. Dadurch verzögerte sich die Implementation des PoC der SmartCard-Anbindung erheblich.

# Kurze Darstellung von etwaigen Ergebnissen bei anderen Stellen
> Gab es Entwicklungen anderer Personen oder Institutionen, die Einfluss auf Deine Arbeiten und die Zielsetzung hatten?

Mehrere Makerspaces haben die Entwicklungen des Projektes verfolgt.
Besonders anzumerken ist hier die Entwicklung eines Spacebetreibers an einem Hardwareprototypen für einen integrierten Kartenleser.
Zeitgleich zu der Prototypefundförderung wurde auch ein Schweizer Team gefördert das in einigen Bereichen Überschneidungen mit FabAccess hat und darauf hin vorschlug Entwicklungszeit anstatt in ihre eigene Insellösung in FabAccess zu stecken.

> Wenn ja, worin bestand dieser und wie bist Du damit umgegangen?

Unser Fokus konzentrierte sich auf die für uns entwickelte Schließhardwareplattform, während andere Plattformoptionen in den Hintergrund traten. Zudem wurden eigenständige Aufgabenpakete entwickelt, die externe Entwickler für uns übernehmen konnten.
Desweiteren wurde ein Zulip-Kanal ins Leben gerufen um eine besser Koordination zwischen den Teams zu erreichen, und dieser dann auch genutzt um einen besseren Kontakt zur weiteren Community aufrecht zu erhalten.