Meeting Notes / Pads

Sicherungskopien aller uns bekannten, geteilten Pads (z.B. CodiMD, HackMD, HedgeDoc) und Protokolle. Warum? Weil Daten im Netz auch mal verschwinden und weil wir an einem zentralen Ort alles besser durchsuchen können! Viele, aber nicht alle dieser Notizen wurden in die laufende Dokumentation eingearbeitet. Dieser Bereich versteht sich als Stöberarchiv.

Solche Pads sind ungeheuer praktisch, da sie die kollaborative Arbeit in Echtzeit ermöglich. Jedoch sind sind nur eine flüchtige, lineare Darstellung von Inhalten, die über die Dauer keinen Zusammenhang ermöglichen - ähnlich, wie Chatverläufe. Es ist äußerst schwer, sie zu pflegen und alle im Blick zu behalten.

Aktuelle News gibt es unter Blog / Historie

13.12.2024 // Koordinationscall Jonny + Mario + Max

Ort + Zeit

Mit dabei

Agenda

Prototype Fund bis Anfang Januar 2025 - wer, was, wie, warum?

Roadmap-Ideensammlung

Mailbox

Leider immer noch kein Mailbox Zugang für Webmaster -> damit kein Management für Google Sitemaps, Sicherheitsmeldungen, Login-Mails oder Kontaktanfragen möglich -> stellt ein großes Problem dar! > Jonny legt ein neues Postfach an und die MX-Records bei den Domains werden entsprechend angepasst. Es betrifft u.a. fab-access.org, fab-access.info, fab-infra.de

Events

Sonstiges

06.11.2024 // FabAccess Community Call

19:00 Uhr bis 20:30 Uhr

mit dabei

Themen

Mario stellt die Sammlung vor, die er bisher angelegt hat. Ziel: Wissen gemeinsam teilen, besonders bei "FabAccess Installation"

Trägerschaft des Hostings evtl. beim VOW? (Das betrifft z.B. Bookstack, Stickergenerator, Demoserver, Download-Bereich --> die Doku soll offline downloadbar sein)

Anschlussfinanzierung für FabAccess möglich? Das könnten auch einzelne Werkstätten organisieren und da könnten dann auch wieder Honorarkosten für Entwicklung bei rausspringen.

Umfrage: Wer mag in Plauen beim Sternenlabor mal einen Besuch abstatten (haben FabAccess in der Elektrowerkstatt schon m Einsatz)?

https://github.com/manyfold3d/manyfold

Tobias vom Attraktor e.V. kümmert sich um Vorstellung FabAccess auf dem CCC --> Fragt in den Gruppen, ob noch weitere Personen aus der FabAccess Community zum CCC in Hamburg kommen

Mario: FabAccess Client installiert mit Waydroid (Android Emulator auf Linux)

Das Bauen der App ist nicht so super easy. Probiert auf Linux und Windows. Wer kann helfen, den aktuellen Client erfolgreich zu kompilieren und das zu dokumentieren? Das ist überdies hilfreich, auch wenn es ggf. irgendwann mal einen Web Client gibt

28.10.2024 // Meeting-Protokoll Koordinationsteam FabAccess

Wo?

https://bbb.cyber4edu.org/rooms/max-7sh-m1t-w95

Wann?

15:00 - 16:15 Uhr

Wer?

Agenda / Themen

23.10.2024 // FabAccess PCB v2 (FabReader)

Meeting Notes

Wann? 23.10.2023 ab 17 Uhr
Wo? https://meet.jit.si/makerspace-gt

dabei

Was soll FabReader grundlegend können?

Gewünschte Features

Abgelehnte Features

Wer macht mit?

Sonstige Notes

10.10.2024 // FabAccess Developer Team Call 10.10.2024

Ort: https://bbb.cyber4edu.org/rooms/max-7sh-m1t-w95/join

Zeit: 14:00 bis 15:10

Anwesend:

Agenda:

Rollenverteilung

29.08.2024 // FabAccess by DSEE

Call am 27.08. mit Jonathan und Andre

Call am 27.08. mit Joseph

Ablauf Call am 12. und 13.12.

Notizen Call mit Joseph, 27.11.2023 nm,bv

Notizen Call mit Joseph am 20.9.2023

Der DSEE-Antrag ist durch. Im Kern geht es um das Aufsetzen von FabAccess in 10 Offenen Werkstätten. Dafür erhalten die Werkstätten Hardware im Wert von 1k sowie 1k für die Bezahlung einer Person vor Ort und Unterstützung durch das FabAccess-Team bei der Umsetzung.

Fragen

Projektrahmen

Projektstart

01.11.2023 - 31.12.2024

Projektdauer

1 Jahr

Projektinhalt

1000€ pro Werkstatt an Hardware
1000€ pro Werkstatt zum Entwickeln
30000€ zum Entwickeln

Umsetzung

Föderation

Wäre mit 10 Werkstätten wäre ein Prototyper Aufbau realistisch

Weitere Föderationsplanung für lokale Bereiche, wie Kleingärtenvereine.

Welche Werkstätten?

Ablauf

Ideen

Nächste Schritte / To-Dos

Leistungsbeschreibungen

Im Rahmen des Projektes “FabAccess” ist geplant die gleichnamige Software- und Hardware-Lösung in zehn Offenen Werkstätten (FabLabs, Maker- und Hackerspaces) einzurichten. Die Technologie steht als Open Source zur Verfügung. Im Rahmen des Projektes sollen die zehn genannten Orte dabei unterstützt werden, das System bei sich zu installieren. Die Orte werden im Rahmen einer Ausschreibung ausgewählt. Für die Umsetzung werden folgende Dienstleistungen benötigt:

Beratung und Betreuung (Paket A)

Beratung

Vorgesehen ist mindestens ein Workshop, bei dem die ausgewählten Werkstätten Grundlagen vermittelt bekommen, wie sie FabAccess technisch aufsetzen und verwenden können. Dabei sollen folgende Dinge vermittelt werden:

Betreuung

Nach der Vermittliung von Grundlagen sollen die zehn Offenen Werkstätten dabei unterstützt werden, FabAccess lokal aufzusetzen aufzusetzten. Folgende Leistungen sind dafür zu erbringen:

Softwareentwicklung (Paket B)

Weiterentwicklung des bestehenden Systems

Für die zehn Offenen Werkstätten werden ggf. neue Plugins benötigt, um bisher nicht unterstützte Aktoren und Sensoren ansteuern zu können. Weiterhin soll der bestehende FabAccess-Stacks zur Verbesserung der Verwendbarkeit und Bedienung weiterentwickelt werden, dabei liegt der Fokus auf folgenden Bereichen:

Entwicklung eines offenen Ausleihsystems

Neben der Weiterentwicklung ist die Entwicklung einer Ausleihstation für Resourcen (Werkzeuge, Maschinen etc.) geplant, die mit FabAcces kompatibel ist und auch von anderen Akteuren, als Werkstätten genutzt werden können soll. Folgende Dinge müssen dafür entwickelt werden:

Dokumentation der Entwicklungen

Alle Entwicklungen werden als Open Source dokumentiert und veröffentlicht. Dabei ist Folgendes zu erbringen:

Hardwarebeschaffung

Optionen zur Hardware

20.08.2024 // Strategiecall am 20.08.2024

Anwesend:Falko(35services), Anjuschm (VOW),Bodo(Werkbox3), Ferdi (ZU Erlangen), Jonathan (ZAM Erlangen), Kevin (ZAM), Mario (Stadtfabrikanten), Michael (Makerspace Güterloh), Roy (MS Leipzig), Jonathan (ZU Illmenau), Joris (Makerspace Bocholt), Mario (Stadtfabrikanen Chemnitz), Michael (Gütersloh), Oleg (OWBA), Roy (MS Leipzig), André (Sternenlabor), Ferdi, Peter (Sternenlabor), Tasso (sfm)

Angeda

10.07.2024 // Laufende Dokumentation im Projekt FabAccess

Hier können alle Learnings und offenen Fragen festgehalten werden. Jede Frage ist wichtig und kann notiert werden. Denkt an ein FAQ, was im Nachhinein entstehen soll.

FAQ - Welche Fragen müssen beantwortet werden, um FabAccess lokal aufzusetzen?

Hier könnt ihr alle Fragen aufschreiben, die bei euch aufkommen:

Interessante Links, die ihr mit anderen Teilen wollt

Andere Notizen, die ihr für wichtig haltet

Hier könnt ihr alles andere niederschreiben, was ihr für andere wichtig findet oder gelernt habt. Wenn ihr mögt, dann schreibt einen eindeutigen Namen hinter eure Notiz, damit wir im Zweifel nachfragen können, falls etwas unklar ist.

➡️➡️➡️➡️ Dokumentation kopiert: https://gitlab.com/fabinfra/fabaccess/docs/-/merge_requests/8 https://gitlab.com/fabinfra/fabaccess/actors/tasmota/-/merge_requests/2 ⬅️⬅️⬅️⬅️

FabAccess Tasmota Actor konfigurieren

Actor verfügbar machen

git clone https://gitlab.com/fabinfra/fabaccess/actors/tasmota.git adapters/tasmota
chmod +x adapters/tasmota/main.py

Actor in bffh.dhall konfigurieren

    actors =
    {
        tasmota_F0A4FB =
        {
            module = "Process",
            params =
            {
                cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
                args = "--host mqtt --tasmota F0A4FB"
            }
        }
    },

Nous A1T / Tasmota konfigurieren

https://tasmota.github.io/docs/Commands/

PowerOnState auf 0 setzen, um eine Art Wiederanlaufschutz zu haben

PowerOnState Control power state when the device is powered up. More information 0 / OFF = keep power(s) OFF after power up 1 / ON = turn power(s) ON after power up 2 / TOGGLE = toggle power(s) from last saved state 3 = switch power(s) to their last saved state (default) 4 = turn power(s) ON and disable further power control 5 = after a PulseTime period turn power(s) ON (acts as inverted PulseTime mode)

Ggf. FriendlyName auf etwas lesbares ändern

!! Fuktioniert das noch mit dem Tasmota Actor? !!

FriendlyName 1 = Reset friendly name to firmware default = set friendly name (32 char limit)

Tasmota aktualiseren

Upgrade 1 = download firmware from OtaUrl and restart 2 = (ESP32 only) download safeboot firmware based on OtaUrl and restart into safeboot = download firmware from OtaUrl if is higher than device version

Werbserver ausschalten und konfiguration nur über MQTT machen

!! Ist dann noch ein separates Netzwerk erforderlich? !!

Webserver 0 = stop web server 1 = start web server in user mode 2 = start web server in admin mode

Farbschema anpassen

https://tasmota.github.io/docs/Commands/#webcolor

WebColor {"WebColor":["#727272","#fafafa","#fafafa","#3f484e","#fafafa","#25d0aa","#3f484e","#ca291d","#1dca29","#000000","#25d0aa","#1a9378","#ca291d","#8a1b14","#25d0aa","#1a9378","#ffffff","#25d0aa","#3b474d"]}

WiFi einrichten

SSId = 1..2 = set AP Wi-Fi SSID and restart 1 = reset AP Wi-Fi SSID to firmware default (STA_SSID1 or STA_SSID2) and restart SSID are limited to 32 characters. Do not use special characters or white spaces in the SSID

Password = 1..2 = set AP Wi-Fi password and restart 1 = reset AP Wi-Fi password to firmware default (STA_PASS1 or STA_PASS2) and restart Passwords are limited to 64 characters. Do not use special characters or white spaces in the password. Note that Password and Password1 are equivalent commands.

MQTT einrichten

MqttHost 0 = clear MQTT host field and allow mDNS to find MQTT host 1 = reset MQTT host to firmware default (MQTT_HOST) and restart = set MQTT host and restart (do NOT use .local)

MqttUser 0 = clear MQTT user name 1 = reset MQTT user name to firmware default (MQTT_USER) and restart = set MQTT user name and restart

MqttPassword 0 = clear MQTT password 1 = reset MQTT password to firmware default (MQTT_PASS) and restart = set MQTT password and restart (min 5 chars)

MqttPort 1 = reset MQTT port to firmware default (MQTT_PORT) and restart = set MQTT port between 2 and 32766 and restart

➡️➡️➡️➡️ Ende von: https://gitlab.com/fabinfra/fabaccess/docs/-/merge_requests/8 und https://gitlab.com/fabinfra/fabaccess/actors/tasmota/-/merge_requests/2 ⬅️⬅️⬅️⬅️

MQTT mit TLS

mosquitto mit traefik einrichten

https://medium.com/@synoniem/running-mosquitto-mqtt-server-with-docker-traefik-and-lets-encrypt-a1f6cbb864cc

ggf. noch mit crowdsec absichern

https://goneuland.de/traefik-v2-3-reverse-proxy-mit-crowdsec-im-stack-einrichten/

ESP8266 unterstützen kein TLS mit Tasmota und muss selbst gebaut werden

https://tasmota.github.io/docs/TLS/#compiling-tls-for-esp8266 !! Durch FabInfra bereitstellen, damit neue Nous per OTA geflashes werden können? !!

platform.ini

                              ; uncomment the following to enable TLS with 4096 RSA certificates
                              -DUSE_4K_RSA

platformio_tasmota_env.ini

lib_extra_dirs              = 
                              ${common.lib_extra_dirs}
                              lib/lib_ssl

tasmota/user_config_override.h

#ifndef _USER_CONFIG_OVERRIDE_H_
#define _USER_CONFIG_OVERRIDE_H_

#ifndef USE_MQTT_TLS 
#define USE_MQTT_TLS                             // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED       true              // [SetOption103] Enable TLS mode (requires TLS version)
#define USE_MQTT_TLS_CA_CERT                   // Force full CA validation instead of fingerprints, slower, but simpler to use.  (+2.2k code, +1.9k mem during connection handshake)
                                                  // This includes the LetsEncrypt CA in tasmota_ca.ino for verifying server certificates
//  #define USE_MQTT_TLS_FORCE_EC_CIPHER           // Force Elliptic Curve cipher (higher security) required by some servers (automatically enabled with USE_MQTT_AWS_IOT) (+11.4k code, +0.4k mem)
#endif

#endif  // _USER_CONFIG_OVERRIDE_H_

Backup / Restore einrichten

Hardware empfehlung

Automatisches Deployment via Ansible?

Hilfsmittel

https://gitlab.com/fabinfra/fabaccess/dockercomposehttps://fab-access.readthedocs.io/en/v0.3/installation/server_docker.html

MQTT Explorer

https://mqtt-explorer.com

27.12.2023 // FabAccess FAQ


FabAccess Tasmota Actor konfigurieren

Actor verfügbar machen

git clone https://gitlab.com/fabinfra/fabaccess/actors/tasmota.git adapters/tasmota
chmod +x adapters/tasmota/main.py

Actor in bffh.dhall konfigurieren

    actors =
    {
        tasmota_F0A4FB =
        {
            module = "Process",
            params =
            {
                cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
                args = "--host mqtt --tasmota F0A4FB"
            }
        }
    },

Noua A1T / Tasmota konfigurieren

https://tasmota.github.io/docs/Commands/

PowerOnState auf 0 setzen, um eine Art Wiederanlaufschutz zu haben

PowerOnState Control power state when the device is powered up. More information
0 / OFF = keep power(s) OFF after power up
1 / ON = turn power(s) ON after power up
2 / TOGGLE = toggle power(s) from last saved state
3 = switch power(s) to their last saved state (default)
4 = turn power(s) ON and disable further power control
5 = after a PulseTime period turn power(s) ON (acts as inverted PulseTime mode)

Ggf. FriendlyName auf etwas lesbares ändern

!! Fuktioniert das noch mit dem Tasmota Actor? !!

FriendlyName<x> 1 = Reset friendly name to firmware default
<value> = set friendly name (32 char limit)

Tasmota aktualiseren

Upgrade 1 = download firmware from OtaUrl and restart
2 = (ESP32 only) download safeboot firmware based on OtaUrl and restart into safeboot
<value> = download firmware from OtaUrl if <value> is higher than device version

Werbserver ausschalten und konfiguration nur über MQTT machen

!! Ist dann noch ein separates Netzwerk erforderlich? !!

Webserver 0 = stop web server
1 = start web server in user mode
2 = start web server in admin mode

WiFi einrichten

SSId<x> <x> = 1…2
<value> = set AP<x> Wi-Fi SSID and restart
1 = reset AP<x> Wi-Fi SSID to firmware default (STA_SSID1 or STA_SSID2) and restart
SSID are limited to 32 characters. Do not use special characters or white spaces in the SSID

Password<x> <x> = 1…2
<value> = set AP<x> Wi-Fi password and restart
1 = reset AP<x> Wi-Fi password to firmware default (STA_PASS1 or STA_PASS2) and restart
Passwords are limited to 64 characters. Do not use special characters or white spaces in the password.
Note that Password and Password1 are equivalent commands.

MQTT einrichten

MqttHost 0 = clear MQTT host field and allow mDNS to find MQTT host
1 = reset MQTT host to firmware default (MQTT_HOST) and restart
<value> = set MQTT host and restart (do NOT use .local)

MqttUser 0 = clear MQTT user name
1 = reset MQTT user name to firmware default (MQTT_USER) and restart
<value> = set MQTT user name and restart

MqttPassword 0 = clear MQTT password
1 = reset MQTT password to firmware default (MQTT_PASS) and restart
<value> = set MQTT password and restart (min 5 chars)

MqttPort 1 = reset MQTT port to firmware default (MQTT_PORT) and restart
<value> = set MQTT port between 2 and 32766 and restart

MQTT mit TLS

mosquitto mit traefik einrichten

https://medium.com/@synoniem/running-mosquitto-mqtt-server-with-docker-traefik-and-lets-encrypt-a1f6cbb864cc

ggf. noch mit crowdsec absichern

https://goneuland.de/traefik-v2-3-reverse-proxy-mit-crowdsec-im-stack-einrichten/

ESP8266 unterstützen kein TLS mit Tasmota und muss selbst gebaut werden

https://tasmota.github.io/docs/TLS/#compiling-tls-for-esp8266
!! Durch FabInfra bereitstellen, damit neue Nous per OTA geflashes werden können? !!

platform.ini

                              ; uncomment the following to enable TLS with 4096 RSA certificates
                              -DUSE_4K_RSA

platformio_tasmota_env.ini

lib_extra_dirs              = 
                              ${common.lib_extra_dirs}
                              lib/lib_ssl

tasmota/user_config_override.h

#ifndef _USER_CONFIG_OVERRIDE_H_
#define _USER_CONFIG_OVERRIDE_H_

#ifndef USE_MQTT_TLS 
#define USE_MQTT_TLS                             // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED       true              // [SetOption103] Enable TLS mode (requires TLS version)
#define USE_MQTT_TLS_CA_CERT                   // Force full CA validation instead of fingerprints, slower, but simpler to use.  (+2.2k code, +1.9k mem during connection handshake)
                                                  // This includes the LetsEncrypt CA in tasmota_ca.ino for verifying server certificates
//  #define USE_MQTT_TLS_FORCE_EC_CIPHER           // Force Elliptic Curve cipher (higher security) required by some servers (automatically enabled with USE_MQTT_AWS_IOT) (+11.4k code, +0.4k mem)
#endif

#endif  // _USER_CONFIG_OVERRIDE_H_

Backup / Restore einrichten

Hardware empfehlung

Automatisches Deployment via Ansible?

Hilfsmittel

https://gitlab.com/fabinfra/fabaccess/dockercompose
https://fab-access.readthedocs.io/en/v0.3/installation/server_docker.html

MQTT Explorer

https://mqtt-explorer.com/

16.03.2023 // Öffentliche Aktivitäten von FabAccess - Stand 16.03.2023

Installationen

Aktiv

Test-Installationen (nícht abschließend)

Avisiert

04.03.2023 // FabAccess Notizen

Community Call 04.03.2023

03.02.2023 // NFC Lib - DESFire

LibLogicalAccess

Müssen wir uns mal anschauen, da die das können, was wir wollen

ISO 7816

Die ISO 7816 spezifiziert in mehreren Teilen die Normen für kontaktbehaftete Chipkarten. Für die DESFire Bibliotheke ist der Teil 4 relevant, da dort die Kommunikation mit der Chipkarte definiert wird.

ISO 7816 Parts

siehe Wikipedia

ISO 7816 Part 4

APDU Command

(wird an PICC gesendet)

CLA INS P1 P2 Lc Data Le
1 byte 1 byte 1 byte 1 byte 1* byte max. 253* bytes 0-3 bytes
siehe Wikipedia

APDU Response

(kommt als Antwort vom PICC)

Data SW1-SW2
max. 253** bytes 2 bytes

siehe Wikipedia

CLA=Instruction Class

gibt an, ob es sich nachfolgend um standardisierte Befehle oder um proprietäre Befehle handelt. Normalerweise 0x90.

INS=Instruction Code

jeweiliger Befehl der ausgeführt werden soll.

P1/P2 = Instruction parameter for command

spezifische Parameter für den Befehl, z.B. ein Offset in der Datie in der geschrieben werden soll.

Lc = commando Length

nennt die Anzahl der Bytes die in [Data] übergeben werden. Kann 1 Byte (max 255) oder 3 (max 65 535, erstes Byte muss 0 sein) Bytes verwendet werden.

Data = command data

Daten die im Zuge des Befehls übertragen werden sollen / als Antwort vom PICC zurückgegeben werden.

Le = response Lenght

Anzahl der Bytes die als Antwort erwartet werden. Dabei stellt 0x00 ein "Platzhalter" für "eine undefinierte Länge bis zu 255 Bytes" da.

SW1-SW2 = Response Trailer

gibt den Anwort-Status wieder, z.B. (Hex): 90 00 für "Command successfully executed (OK)" 91 00 für "OK" siehe Response codes

"*" / "**" wir verwenden maximal 255 bytes, da ansonsten die Datenübertragung mittels MQTT sehr lang werden könnte.

Beispiel

select Application 0xC0FFEE siehe OTA Beispiel

Parameter Wert Kommentar
CLA 0x90 Standard Befehlssatz
INS 0x5A select Application
P1/P2 0x00/0x00 keine zusätzliche Parameter
Lc 0x03 3 Bytes
Data 0xEE, 0xFF, 0xC0 umgekehrte Reihenfolge(?)
Le 0x00 0x00 = maximal 255 bytes

Befehl: "\x90\x5A\x00\x00\x03\xEE\xFF\xC0\x00" bzw. 905A000003EEFFC000

Antwort "\x91\x00" bzw 9100

Parameter Wert Kommentar
Data - Befehlt erwartet keine Daten (Le=0)
SW1/SW2 0x91, 0x00 "OK"

Befehle

Wrapping von DESFire Native Commands in ISO 7816-4 APDU Frames. ClA(Class) = 0x90 (Bei allen Commands für die Karte) INS(Instrucation) = Command Code des jeweiligen Befehls

Glossar

AID = Application ID

Jede Application auf der DESFire Karte hat einen eigenen Identifier. Ein AID ist 3 Byte groß.

PICC = Proximity Integrated Circuit Card

Die Chipkarte selber

IV = Initialisierungsvektor

Ist ein Begriff aus der Kryptographie und bezeichnet einen Block von Zufallsdaten, der in bestimmten Modi einiger Blockchiffren verwendet wird, wie dem Cipher Block Chaining Mode.

CBC = Cipher Block Chaining

Ist eine Betriebsart, in der Blockchiffren betrieben werden können. Vor dem Verschlüsseln eines Klartextblocks wird dieser zunächst mit dem im vorhergehenden Schritt erzeugten Geheimtextblock per XOR (exklusives Oder) verknüpft.

Datenstruktur Low Level

PCB [CID] [NAD] [INF] EDC/CRC
0x0A 0x00 n.v. APDU data specific
1 byte 1 byte 1 byte max. 253 bytes 2 bytes

PCB = Protocol Control Byte (low level, prologue field)

Ist Teil der "Umkapselung" eines APDU Kommandos in der Kommunikation mit dem PICC. Im Normalfall 0x0A (Information Block, no chaining, CID follows, no NAD, BlockNr = 0).

CID = Card ID (low level, prologue field)

Ist Teil der "Umkapselung" eines APDU Kommandos in der Kommunikation mit dem PICC. Ist der Identifizierer des aktuelle PICCs. Ist nur relevant, wenn mehrere PICCs vom Leser gleichzeitig erkannt wurden und nacheinander selektiert wurden. Bei der Kommunikation mit nur einer Karte immer 0x00.

NAD = Node Address

Identifizierer für Absender und Empfänger. Wird nicht verwendet.

EDC / CDC = Error Detection Code / Cyclic Redundancy Check (low level, epilogue field)

Ist Teil der Umkapselung von jeder Nachricht an einem PICC. Wird forlaufend berechnet. Wird häufig von der Hardware selbst berechnet, muss jedoch manuell vom Programm angehangen werden.

INF = Information Field

ist der Teil der Nachricht mit der Infromation mit der Karte ausgetauscht werden kann. Hier können einfache Kommandos oder APDUs verwendet werden

APDU definition

Get Application IDs

APDU Case: 2

Command Code P1 P2 Data
0x6A

The “Get AID List” command return the Application Identifiers of all active applications on a PICC.

0x000000 is PICC Application ID, is always returned.

TODO: 4 or 3 Bytes AID size TODO: MSB or LSB first

Select Application by AID

APDU Case: 3

Command Code P1 P2 Data
0x5A AID (3 Byte, MSB first)

The “Select Application” command allows to select one specific application for further access. If this parameter is 0x000000, the PICC level is selected and any further operations are related to this level. If an application with the specified AID is found in the application directory of the PICC, the subsequent commands interact with this application.

AuthenticateISO

Get Challenge APDU Case: 4

Command Code P1 P2 Data
0x1A key_id (1 Byte)

Send Challenge APDU Case: 4

Command Code P1 P2 Data
0x5A challenge (MSB first)

Authentication Process Authentication Process

Beispiel zum Beispiel

Zur Crypto Es wird CBC verwendet.

Zum Entschlüsslen von rndB wird der IV auf 0 gesetzt.

The IV of the session key is reset to zero only ONCE when the key is created after authentication. The IV of the authentication key is reset only ONCE when authentication starts.

Bei allen anderen Verschlüsselungen oder Entschlüsselungen wird der letzte verschlüsselte Block als IV verwendet.

Response Codes

[TODO: Copy from eftlab.com]

Over the Air

Ablauf Kommunikation

Authentication

// Reader
1. Authenticate against lokal BFFH
2. Start Proxy Session
3. Meldet die Präsenz einer Karte


// Client
1. Start Proxy Session

// Lokale BFFH
MifareDESFire mifareDESFire = new MifareDESFire(card);

mifareDESFire.SelectApplication(FabAccessAID);

// FabAccessIdentFileID ist unverschlüsselt
byte[] filedata = mifareDESFire.ReadData(FabAccessIdentFileID, 0x00000000, 0x00000000);

System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
string userdomain = enc.GetString(filedata);

Console.WriteLine(userdomain);

// Domain BFFH
// Der Eigentümer der Karte
mifareDESFire.SelectApplication(FabAccessAID);

mifareDESFire.Authenticate(0x01, APP_Key_1);
// jetzt wissen wir, das die Karte Authentisch ist

byte[] filedata = mifareDESFire.ReadData(FabAccessIdentFileID, 0x00000000, 0x00000000);

System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
string userdomain = enc.GetString(filedata);
// jetzt wissen wir, dass die Domain auch wirklich auf die Karte ist

// jetzt müßte man noch einmal die UID der Karte abfragen, um sicher zu stellen, dass der User auch der ist, für den er sich ursprünglich ausgegeben hat.

connected_successfully = true;

card.Disconnect();

Troubleshooting

Error 0x910B

Reinstall NFC Driver on Windows

Quellen

NXP / Mifare

Allgemein

Mifare Application Directory Missing Native Commands

MIFARE DESFire spezifisch

Produktübersicht

EV1 Factsheet EV2 Factsheet EV3 Factsheet

Datasheets

EV1 Datasheet EV2 Datasheet EV3 Datasheet Light Datasheet

Features

Over the Air EV3 Features EV3 Quick Start

Generic Access Control Model System Level Security PHILLIPS Presentation PHILLIPS DESFireSAM Authentification Spec ISO/IEC 14443 Type 4 Tag ISO/IEC 14443 Communication Error Code - 0x6A81

ISO

MIFARE ISO/IEC 14443

externe DESFire Spezifikationen oder Dokumentationen

DESFire OTA - Proof of Concept Ridrix DESFire Commands MIFARE DESFire Short Spec DESFire KeySettings Response Codes DESFire Authentification DESFire Command Set AES Authentication PHILLIPS DESFire Specification

ISO Specifications

ISO 7816-4 ISO/IEC7816-4

andere NFC Bibliotheken (mit DESFire)

JavaCardOS Easypay Android Java App RFID Door Lock RFDoorLock DESFire Server libfreefare DesFire for Python libopenkey mfrc522 LibLogicalAccess

Müssen wir uns mal anschauen, da die das können, was wir wollen

DESFire Auth 2K3DES Authentication Question Kommunikationsbeispiele DESFire CRC Question

unsere Mitschnitte der Kommunkation verschiendener Bibliotheken

OTA Proof-of-Concept

07.12.2022 // Chat & Notizen FabAccess-CommunityCall

Notizen

Agenda: 
- Intro
- Check In
- Technisches

- FabAccess: Wie kam es dazu?
- Was ist FabAccess? + Demo
- Fragen
- Konkrete nächste Schritte
 
-Check Out

Wie es kam dass es kam so dass es ist wie es ist:

2018: VOW & Fab:UNIverse (noch) einzeln unterwegs.
2019: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ#
2020: https://media.ccc.de/v/rc3-326175-fabaccess
2021: https://prototypefund.de/project/fabaccess/
2022: https://wiki.fabcity.hamburg/software-department/fab-city-os

Test-Server:
test.fab-access.org
Login:
Admin1
Admin2

ManagerA1
ManagerA2
ManagerB1
ManagerB2
ManagerC1
ManagerC2
ManagerABC1
ManagerABC2

MakerA1
MakerA2
MakerB1
MakerB2
MakerC1
MakerC2
MakerACB1
MakerACB2
MakerACB3

GuestA1
GuestA2
GuestB1
GuestB2
GuestC1
GuestC2
GuestACB1
GuestACB2

MakerQRA
MakerQRB
MakerQRC

Passwort: secret

Fragen:

**Was genau bedeutet ausschalten? **

Was für ein Schloss habt ihr dafür für das Türschloss genommen?
Equiva, Dazu gibt es einen Controller auf Basis von KeyBLE
Für Nuuki soll etwas entwickelt werden.

Wo ist der Unteschied zwischen einer Maschine in Benutzung und einerm geblocketen Schließfach?

Wie ist die Interaktion von User und FabAccess?
Jeder Nutzer kann sich die App runterladen, bekommt eigene Zugangsdaten und können sich selber anmelden, bzw. Maschinen anschalten. Auf den Maschinen stehen QR-Codes, die von den Handys gescannt werden können. Es wird noch an einem NFC-Prozess gearbeitet.

Das System ist modular: Es gibt eine App. Zweiter Weg: Es gibt einen Kartenleser (open source hardware), einfach nachzubauen. Die Nutzer*innen bekommen Chip-Karten, die auf den Kartenleser aufgelegt werden, dann geht die Maschine an. Es gibt auch die Variante, dass die Karte nur kurz drangehalten wird, die Maschine angeht, die Karte nochmal drangehalten wird, die Maschine aus geht.

Erfolgt der Zugriff von der App auf den Server lokal via WLAN oder muss der Server öffentlich erreichbar sein? dh. es geht auch nur mit lokalem WLAN?
Antwort: Ja

Gibt’s auch eine Weboberfläche? Bzw ist das geplant?
Antwort: Nein noch nicht. Derzeit gibt es im Kernteam von FabAccess keine Ressourcen dafür. Wenn das wer machen würde, würden wir untersüttzen. Man bräuchte aber auch einen Webserver, weil wir kein API, das selber mapt auf (?)

Was heißt NFC?
Kontaktlose Datenübertragung, z.B. wenn man die EC-Karte zum Bezahlen nur dranhält. Die Karten kommunizieren mit den Lesegeräten ende zu ende verschlüsselt.

**Rückfrage zum Terminal: Das Terminal würde dann auch nutzbar sein Maschinen an- und auzuschalten und nicht nur dazu, Dinge auszuleihen? **

Antwort: Ja genau.

Wie verhindert man, dass es möglich ist, dass der nächste der kommt, Maschinen mit meiner Karte anschalten kann?
Antwort: Ist noch in Arbeit

Wie wollt ihr mit Mehrfachanmeldungen umgehen? Wenn wer die Berechtigung für drei Maschinen hat?
Antwort: Bisher ist es möglich udn auch gewünscht, dass mehr als eine Maschine genutzt werden kann. Die Totmannschaltung ist noch in der Entwicklung: Wenn die Maschine nicht mehr genutzt wird, schaltet sich die Maschine ab.

Wie administriert ihr, bzw. die anderen Labs die schon im Probebetrieb sind heute die User?
Also User Anlegen und Berechtigungen editieren. Entweder über eine Textdatei oder über die Referenz-App auf dem Handy.

Antwort: das kann man mittlerweile direkt über die App mit der Adminrolle

Nachtrag: Wie teuer ist das Aufsetzen eines FabAccess Systems
Server - alternativen:

  1. alter Linuxrechner - meistens geschenkt
  2. Raspberry Pi - 70€
  3. kleiner Server ( z.B. Intel NUC, evtl. mit Proxmox) 200-400€

Schalter - alternativen (pro Maschine)

  1. Relais-Board mit ESP-01 Modul - ab 3,50€
  2. Shelly 1 - 12-16€
  3. Shelly 1PM (mit Strommessung) - 15-20€
  4. 3-Phasen Schalter - Ralais-Board oder Shelly 1 + 3-Phasenschütz ca. 17€

Client (d.h. Gerät mit der Maschinen freigeschaltet werden)

  1. App “Fabaccess” - kostenlos
  2. FabReader Bausatz - ca. 20€
  3. Computer mit Windows und FabAccess-Client

Chat

[18:01] Anjusch: @jens @markus Könnt ihr uns schon hören?
[18:01] Anjusch: Falls es nicht funktioniert, geht nochmal aus dem Raum raus und wählt euch nochmal ein. Das hilft oft.
[18:01] Markus (Helldogz): leider nicht, bin mir nicht sicher wo das Problem ist
[18:02] Anjusch: Eventuell mit einem anderen Browser probieren?
[18:02] Marcel: hast du es mal mit ausschalten und einschalten versucht 🤣
[18:03] Jens, Konglomerat e.V.: ich habe noch kein Ton…
[18:03] Marcel: vielleicht einen anderen Browser versuchen?
[18:06] Nils (FabLab Karlsruhe): Wäre nett, wenn ihr nicht aufzeichnet.
[18:06] Mulzer, Tasso: Entspannt, gespannt und gut gelaunt. ;)
[18:06] Leopold Zyka (OpenLandLAB): Wir sind gerade Fab Region Südbrgenland geworden
[18:07] Joris: hier in Bocholt alles gut, ebenfalls entspannt, da diese Woche endlich mal was ruhiger
[18:07] Leopold Zyka (OpenLandLAB): Bitte aufzeichnen!
[18:07] Stefan (Hobbyhimmel Stuttg: Es geht gut, bin noch bei der Arbeit und höre gespannt zu!
[18:07] sn0wdiver: Entspannt , und neugierig
[18:07] Marcel: Ich freu mich dass das Thema nun doch etwas Fahrt aufnimmt ;) bin gespannt wie ich helfen kann
[18:08] sn0wdiver: sitze in Wuppertal
[18:08] Sebastian S. (werkbox-VS): Südbaden
[18:08] Nils (FabLab Karlsruhe): Wir planen in Karlsruhe seit längerem ein Access System und finden es klasse, dass ihr jetzt ein offenes System für viele Fablabs entwickelt.
[18:08] Marcel: ouha joris ich glaube dein Laptop hat das falsche mikro, denn es gab viel Hall
[18:09] Leopold Zyka (OpenLandLAB): Schade ich muss in ein anderes Meeting
[18:09] Stefan (Hobbyhimmel Stuttg: Wir der Hobbyhimmel sind gespannt was es neues gibt… denn wir haben Bedarf dafür.
[18:09] Joris: weiß nur nicht wie ich das auf Anhieb ändere. Wähle mich zur Not gleich einfach noch mal ein
[18:12] Michel Heftrich: Acces System eine große Hilfe?
[18:17] Mulzer, Tasso: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ#
[18:18] dequbed: https://xkcd.com/927/
[18:18] Mulzer, Tasso: https://media.ccc.de/v/rc3-326175-fabaccess
[18:20] Mulzer, Tasso: https://prototypefund.de/project/fabaccess/
[18:30] Joseph (FabAccess): https://hobbyhimmel.de/so-gehts/einweisungen/
https://www.werkbox-vs.de/faq-haeufig-gestellte-fragen/#hfaq-post-1652
https://fablab-karlsruhe.de/2016/03/21/bohrmaschinen/#
[18:31] Nils (FabLab Karlsruhe): Kannst du vielleicht noch einen kleinen Überblick geben, was aktuell schon gut nutzbar ist bzw. schon in einem Lab genutzt wird.
[18:35] Anjusch: https://www.offene-werkstaetten.org/post/cowiki-yeah
[18:42] Joris: zum Protokollieren der Nutzer haben wir in Bocholt ein Python skript geschrieben.
[18:43] Nils (FabLab Karlsruhe): Die automatische Abschaltfunktion ist eine klasse Idee 👍
[18:45] Joris: … eine Anbindung zu einem Bluethooth-Türschloss haben wir auch schon geschrieben
[18:46] sn0wdiver: Was für ein Schloss habt ihr dafür genommen?
[18:48] Joris: schaue nach
[18:48] Joris: Equiva
[18:49] Joris: Dazu gibt es einen Controller auf Basis von KeyBLE
[18:50] Marcel: wo ist der Unteschied zwischen einer Maschine in Benutzung und einerm geblocketen Schließfach?
[18:50] Joris: https://github.com/oyooyo/keyble
[18:55] Nils (FabLab Karlsruhe): Erfolgt der Zugriff von der App auf den Server lokal via WLAN oder muss der Server öffentlich erreichbar sein?
[18:56] Dirk: Und noch eine Rückfrage: gibt’s auch eine Weboberfläche? Bzw ist das geplant?
[18:57] Nils (FabLab Karlsruhe): dh. es geht auch nur mit lokalem WLAN?
[18:57] dequbed: Nils: Ja
[18:58] Joris: ja, bei uns haben wir Freifunk, und fangen die IP mit der sich die Handys verbinden für den Server ab.
MQTT läuft dann über unser geschlossenem (W)LAN
[19:01] Nils (FabLab Karlsruhe): Gibt es die Möglichkeit ein Terminal aufzusetzen, an dem ich mich z.B. per RFID authentifiziere und dann die maschinen wie in der app sehe? Sprich Display und RFID Reader zentral an einer Stelle, statt einem Reader pro Gerät.
[19:03] dequbed: NFC ist das was genutzt wird wenn man seine EC-Karte auf den Reader draufhällt anstatt einsteckt
[19:03] Nils (FabLab Karlsruhe): Und vorbildlich ist auch, dass ihr nicht nur die UID verwendet. :-)
[19:05] Falk: Wie Administriert ihr, bzw. die anderen Labs die schon im Probebetrieb sind heute die User?
Also User Anlegen und Berechtigungen editieren.
[19:07] Joris: Falk: das kann man mitlerweile direkt über die App mit der Adminrolle
[19:08] Nils (FabLab Karlsruhe): Könnt ihr vielleicht mal kurz die Userverwaltung zeigen, würde mich auch interessieren, was da aktuell schon alles implementiert wurde.
[19:08] markus_EBK: Vielen Dank an euch und bis zum nächsten mal.
[19:08] Anjusch: Schüss Markus
[19:11] dequbed: Also es wird immer (pro-Maschine) konfigurierbar sein.
[19:11] Nils (FabLab Karlsruhe): Das mit der Karte auf dem Reader scheint mir aber sehr riskant, denn wenn die Verbindung zur Karte abbricht, obwohl sie noch da ist und dann die Maschine ausgeht, wäre das sehr unglücklich.
[19:13] Nils (FabLab Karlsruhe): @Stefan: Das sind auch unsere Wünsche :-)
[19:13] Sebastian S. (werkbox-VS): Oder wenn die Karte wegen Vibrationen einfach runterfällt…
[19:13] Herzlich Willkommen zum Webkonferenzraum: FabInfra der BHT!In unseren Videotutorials finden Sie Tipps und Hinweise zur Nutzung von BigBlueButton.Verwenden Sie bitte ein Headset, um Störungen durch Nebengeräusche zu vermeiden.Um dieser Konferenz per Telefon beizutreten, wählen Sie die Telefon-Nummer:+49 30 208470609 und geben 27736 als Konferenz-PIN ein. Für die anonyme Einwahl bitte #31# vorwählen.Hinweis: Anrufer sind ggf. stummgeschaltet. Drücken Sie 0 um zu sprechen bzw. sich stummzuschalten.
[19:13] Um jemanden zur Konferenz einzuladen, schicken Sie ihm diesen Link: https://conference.beuth-hochschule.de/b/mul-h26-gct
[19:14] Marcel: https://www.shelly.cloud/shelly-pro-smart-home-automation-solution/#Pro-3
[19:16] Joris: wir haben das gleich im Sicherungsschrank eingebaut
[19:21] Dirk: Ich hätte noch eine Frage in eine andere Richtung: das letzte mal als ich die Dokumentation angeschaut habe, habe ich kein “für ein einfaches Setup brauchst du genau diese Hardware und diese Software Komponenten” gefunden sondern eher nur “das gibt es alles”. Gibt es da inzwischen eine art Tutorial?
[19:24] Falk: in den Shared Notes habt ihr Zugangsdaten zu einem Testsystem, wie ist denn dafür das jeweilige Passwort?
[19:24] Joseph (FabAccess): secret
[19:25] Sebastian S. (werkbox-VS): Was für ein Budget sollte man ansetzen, wenn man dazu ein Projekt aufsetzen möchte? Also natürlich Abhängig von Anzahl Maschinen/Schließfächern etc. die man steuern möchte…
[19:26] Nils (FabLab Karlsruhe): Gibt es ein FabLab, wo wir uns das mal live vor Ort anschauen können?
[19:27] Joris: Nils: in Makerspace Bocholt
[19:27] Stefan (Hobbyhimmel Stuttg: Muss leider los. Vielen Dank! Bei Fragen bitte melden Stefan@hobbyhimmel.de
[19:28] Nils (FabLab Karlsruhe): Bocholt wäre machbar :-) Würde mich über Kontaktdaten freuen.
[19:28] Dirk: Habt ihr ein kozept um zu verhindern, dass der Shelly einfach “ausgebaut” wird? Also stecker direkt in die Steckdose?
[19:28] Sebastian S. (werkbox-VS): Danke. Könnt ihr das nochmal in die Notizen packen? Dann kann man das mit Zeitversatz auch noch kalkulieren… ;-)
[19:28] dequbed: Dirk: Kleber! :D
[19:29] sn0wdiver: ich komm in Bocholt mal vorbei, von Wuppertal ist es ja nicht so weit
[19:29] Joseph (FabAccess): gitlab.com/fabinfra
[19:29] dequbed: https://gitlab.com/fabinfra/
[19:30] Anjusch: https://matrix.to/#/!pIikowJsyqburBAIac:vow.chat?via=vow.chat&via=matrix.org
[19:31] sn0wdiver: ich bau mir das mal auf und hab dann in 14 Tagen viele Fragen ;)
[19:31] Nils (FabLab Karlsruhe): bei fragen/problemen zum linux client compilieren: bietet sich da der nächste Call an oder per Matrix bei euch melden?
[19:31] Marcel: das zulip chat hat sich damit erledigt?
[19:32] Joseph (FabAccess): ja
[19:32] Joseph (FabAccess): @Marcel schreibe ich auch da nochmal rein
[19:32] Mulzer, Tasso: https://www.offene-werkstaetten.org/post/fabaccess-community-calls
[19:32] Jens2 Konglomerat e.V.: Danke auch !!!
[19:33] sn0wdiver: Danke für eure Engagement
[19:33] Nils (FabLab Karlsruhe): Vielen Dank für den informativen Abend und die viele Arbeit, die ihr euch macht.
[19:33] Mulzer, Tasso: info@fab-access.org
[19:33] Joseph (FabAccess): info@fab-access.org

24.04.2022 / Roadmap

Roadmap

API Version v0.3 - April 2022

Content of API:

  1. Ausleihen von Maschinen (Use, Check, Block, Disable)
  2. Übertragen von Maschinen - ???
  3. Verwalten von Nutzern (Add, Remove) - 15.05.2022
  4. Ändern von Nutzerrollen - 15.05.2022
  5. Hinzufügen von FabFire Karten zu Nutzern - ???

AuditLog

TODO:

QR-Code für Maschinen NFC für Maschinen GTK und MacOS UWP im Store

Mehr Infos zu 3. und 4.: Anbinden von externen IDPs Persistenz von Nutzerdaten nach Server neustart BackUp von Nutzerdaten

API Version v0.4 - August 2022

Content of API:

  1. Komplexe Status
  2. Live Notes an Ressourcen die nur für ≥Manager sichtbar sind. (Blame)

Mail

Hello!

since two of our guys couldn't join the meetings I'll recap the main points from the two meetings last week:

We scheduled tentative weekly 30-minute meetings every Tuesday at 15:50 CEST for further establishing details of the integration of FabAccess in the INTERFACER project, starting out with somewhat longer meetings and getting shorter as required. The main topics that were identified to require further discussion are the requirements that FabAccess poses to the existing IAM software solution, especially special topics like card management, to refine the requirements for the FabAccess milestones in the current roadmap, and conduct research on the design and implementation of the FabAccess token and other integrations with the FabChain.

Regarding the Milestones, an initial draft:

Milestones

Since out reference client tracks our server software closely features generally require code on both sides and aren't itemized separately.

  1. Release 0.3 — "Spigots of Berlin" by 2022-04-24
    • Features implemented
      • Audit log
      • internal user auth & roles
      • NXP DESFire based authentication system
      • 5-state machine model
      • Actor / Initiator system
      • Configuration of some machine metadata
      • Basic UI for machine state interactions
  2. Release 0.4 — "Digging up Stuttgart" by 2022-08-31
    • Features implemented:
      • OIDC Service Provider
      • User roles sourced from external sources (e.g. LDAP)
      • Framework allowing additional machine models to be implemented
      • Dynamic UI capable of displaying complex states required by some machine models
      • Client support for OIDC auth
  3. Comprehensive documentation of Beta Diflouroborane and Borepin. by 2022-09-30
    • Primary Focus Setup and Pre-Production enviroments
  4. Final (INTERFACER) Release — by 2022-12-31
    • Features implemented:
      • Templating allowing for custom corporate designs
      • Publishing OpenHardware CardSystem
      • Python/Lua Scripting API
  5. Comprehensive documentation of Release Diflouroborane and Borepin. by 2022-12-31
    • Primary Focus End-Users and Common Production Setups
  6. Follow-up support, up to 2023-03-31
    • incl. assisting INTERFACER testing/integration setups

API information

API schema language is https://capnproto.org/ language reference can be found at https://capnproto.org/language.html

A Python API test script can be found at https://gitlab.com/fabinfra/fabaccess/pyfabapi

In the following a very short explanation of the contents of each schema file:

connection.capnp

Initial starting point for API interactions with an instance of the interface Bootstrap being send to each client on connection establishment.

authenticationsystem.capnp

SASL-based authentication returning an instance of struct Session from connection.capnp on successful authentication, giving access to some or all Subsystems based on user roles.

machinesystem.capnp

Lookup system for machines based on URN or configured names.

permissionsystem.capnp

Administrative access to internal roles.

usersystem.capnp

Lookup & admin access to internal representation of users.

machine.capnp

Machine object methods allowing state updates following the current 5-state model and administrative access for privileged operators.

user.capnp

Access to user information and administrative methods for privileged operator.

space.capnp && general.capnp && role.capnp

Auxiliary types used in other files.

Test env

We have a test environment with a preconfigured server. https://gitlab.com/fabinfra/fabaccess/testenv

All available test users are listed in the README.md file. For a simple start the "Admin1" user is the most useful.

The password for all users is "secret".

The test server is currently running at "test.fab-access.org:59661"

Please write if you need clarifications on any subject matter.

Greetings, dequbed & Joseph

Naming Things

0.?

https://de.wikipedia.org/wiki/Historisches_Archiv_der_Stadt_K%C3%B6ln#Einsturz_des_Geb%C3%A4udes_im_M%C3%A4rz_2009

Ideen:

0.??

Elbphilharmonie

Ideen:

0.???

https://de.wikipedia.org/wiki/GAIA-X

Notes

Recap mail aka. CYA cryptobros edition

Hello all,

since two of our guys couldn't join the meeting I'll recap the main points from the meeting earlier today:

Updating the information we had so far Adam is the technical manager for the work-package of FabAccess in INTERFACER, making him our primary contact person for technical issues instead of Henry. As Henry and I have discussed in January we'll want to have a test setup before a more precise priority list for the requirements is made.

We scheduled a follow-up meeting on 2022-04-19 at 15:50 CEST, and decided tentatively to make the 15:50 slot every tuesday a weekly meeting for further establishing details of the integration of FabAccess in the INTERFACER project, starting out with somewhat longer meetings as required.

The main topics that were identified to require further discussion are the requirements that FabAccess poses to the FabCityOS IAM system, especially special topics like card management, and to refine the requirements for the FabAccess milestones in the current roadmap.

Please tell me if you spot any mistakes.

Greeting, dequbed

24.01.2022 // Mitschrift HTW

Jana, Cristopher, Martin Ideas in Action Martin zukünftiger Leiter des Makerspaces Paul SHK - Raumbuchungssystem Wojtek Prof. - Raumbuchungssystem - IT Zuständig Erich Rother KI-Werkstatt - Einrichten eines Raumbuchungssytem/Resourcenbuchungssystem

Kooperation des Systems mit dem Raumbuchungssystem Projekt Ideas, bei dem interaktive und kreative Labore enstehen sollen, wo Studierden aktiv werden sollen.

KI-Werkstatt, Interaktive Geräte zu KI Themen

Raumbuchungssystem für Kurse über VMs bis zu einer Säge -> Menschenverwaltet

Intergration in LSF (Hochschulsystem)

26.12.2021 // Name for the Abstraction Layer of the Server and the Protokoll in Capn Proto

Bedingung: Es muss aussprechbar sein und sprachlich übermittelbar

Idee: irgendwas mit Kleber

14.12.2021 // Install FabAccess

Install FabAccess

Minimal Hardware Requirements

Server

tl;dr No Hardware Requirements known so far. No all Platforms are supported with Docker Images.

or if building a custom PC just so you can run FabAccess is too much effort; a Raspberry Pi is fine, although RasPi 2 and up are recommended. Any one really (exept: Raspberry Pi 1 or Raspberry Pi Zero).

Client

Android SDK Version: 21 iOS Version: 13 Windows 10: 1709 - Build:16299

Internal Release

Internal Release is only for our Space to develop FabAccess and distribute the Server and the Client easier to our users. We keep everything Open Source, but we not want to fear your users with to many bugs.

Beta Release

To not overcomplicate our CI/CD and developent process this acctual "Beta" is more an "Alpha" for intreseted testers.

Install the Server

Option 1. rustup && cargo install

Steps:
  1. Install rustup.rs. Distribution packages for rustc are generally way too old
  2. $ rustup install stable
  3. Get yourself a directory to clone BFFH into
    • If you put this dir on a SSD you can speed up build times by 5-10 times.
  4. git clone --recursive --branch stable
    • ... stable ... TODO...
    • You can also check out the development branch but keep in mind that until Beta it has no stability guarantee. It may work. It may make you a sandwich. But it may also set your hat on fire and fill your shoes with orange juice. You have been warned.
  5. cargo install --path .
    • if you add --debug you get a debug build. It gives you much more logging output but it's slower to run and is almost spammy
  6. Make yourself a coffee. Or tea. Or open $beverage of your choice. You earned it! (And you'll be looking at "Compiling " for a while.)
    • If you get error: failed to run custom build command for 'gsasl-sys v0.2.3' or something like that with the stderr output reading "[…]Unable to find libclang[…]":
      • export LIBCLANG_PATH=/usr/lib Or wherever libclang.so is installed on your computer. It's usually /usr/lib/libclang.so or /usr/lib/llvm/12/lib/libclang.so or similar. If you can't find it, consult your package manager
    • If you get any other error open an issue

Option 1.1 Install on Ubuntu for "Dummies"

- see further below, as t his is a bit of a lengthy process...

Option 2. Docker

Docker Image can not run on armv6 (Raspberry Pi 1 or Raspberry Pi Zero)

Steps:
  1. Install Docker On Raspberry Pi: https://phoenixnap.com/kb/docker-on-raspberry-pi
  2. Install Docker-Compose On Raspberry Pi: https://dev.to/elalemanyo/how-to-install-docker-and-docker-compose-on-raspberry-pi-1mo
  3. Get Docker-Compose Files git clone https://gitlab.com/fabinfra/fabaccess/dockercompose.git The Dockerfile is in the root directory of the main repo docker-compose.yml is available in a seperate git repo
  4. Edit config files in config folder to taste
  5. Start Server with docker-compose up -d

To make it eaysier to apply youre changes in your config and keep the dockercompose uptodate, you should "fork" this respository.

Get Server Logs

docker-compose logs

Install the Client

Currently only Windows(UWP), Android and iOS are directly supported.

Option 1. Platform App Store

Android: https://play.google.com/store/apps/details?id=org.fab_infra.fabaccess iOS: https://testflight.apple.com/join/KfeUaHT4 Windows:https://www.microsoft.com/de-de/p/fabaccess/9p69mwzjf2mv

Option 2. Build locally

Follow build instructions on: https://gitlab.com/fabinfra/fabaccess/borepin

... and now for something completely different...

Option 1.1 Install on Ubuntu for "Dummies"

This description is how to compile and set up Diflouroborane on Ubuntu 20.04.3 LTS clean install. Other releases or distros might work as well. The process is quite lengthy but at the end you will have a FabAccess running to you needs. ... as I said: for complete dummies, if someone finds a better solution, please post suggestions on: https://fabaccess.zulipchat.com/#narrow/stream/255963-General/topic/Demo

Steps

  1. Get your system up-to-date sudo apt-get update && sudo apt-get upgrade

  2. Get rustup sudo apt install curl curl --proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh restart the console

  3. Get capnproto, gsasl and git sudo apt-get install gsasl sudo apt-get install capnproto sudo apt install git

  4. Create a target directory for BFFH there might be better places compared to where I created it, but it works... mkdir BFFH cd BFFH

  5. Clone the Diflouroborane repository git clone https://gitlab.com/fabinfra/fabaccess/bffh

  6. For compiling some dependencies were missing on Ubuntu git submodule update —init sudo apt install libgsasl7-dev sudo apt install cmake sudo apt install libclang-dev sudo apt install libssl-dev sudo apt install cargo

  7. Open the subdirectory and start compiling cd bffh cargo build --release if the compiler prompts somthing like "error: linker 'cc' not found": sudo apt install build-essential cargo build --release

  8. Copy the configuration files (best done with the GUI filemanager of Ubuntu) copy files from "bffh/examples" paste them into "bffh/target/release/examples"

  9. Install mosquitto MQTT broker Diflouroborane uses mosquitto MQTT broker to communicate with the Shellies. sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa sudo apt-get update sudo apt-get install mosquitto sudo apt-get install mosquitto-clients sudo apt clean find out which linux release is installed (for Ubuntu -> google) uname -a sudo wget http://repo.mosquitto.org/debian/mosquitto-bullseye.list change "bullseye" according to your distro: bullseye, buster, stretch, jessie, ...

  10. Configuring mosquitto broker for some reason, starting with version 2.x mosquitto does not allow external communication via the broker per default. This needs to be changed via a config file:

  11. Stop mosquitto sudo service mosquitto stop

  12. Change into the "etc/mosquitto/" directory (lots of cd .. then cd etc, cd mosquitto)

  13. Create a configuration file: sudo touch file test.conf

  14. Edit the configuration fil: sudo nano -w test.conf add: listener 1883 allow_anonymous true Save (Strg-O) and close (Strg-X)

  15. Start mosquitto mosquitto -v -c /etc/mosquitto/test.conf

  16. Find the IP adress of your computer - new console ip a

  17. Configure your Shelly as long as your Shelly has not been given the credentials for a WLAN, it will create an access point (AP) for configuration. This AP will appear in your list of WLAN. Connect to this Shelly-AP and connect to 192.168.33.1 in your browser. A configuration page should appear. If your Shelly is already connected to your WLAN, you must find the assigned IP-Adress (e.g. by looking into your router). Enter this IP Adress in your browser and you will get the configuration page.

  18. MQTT Client setup goto "Internet & Security" -> "Advanced - Developer Settings" enable "MQTT" enter the IP-Adress from Step 16 in the field "IP-Adress" As we did not define MQTT credentials in mosquitto yet, no creadentials need to be filled in. To find the "ID" of your Shelly activate "Use custom MQTT prefix" (but do not change it!). This should be somthing like: shelly1-123456789ABC for a Shelly 1 shelly1pm-123456 for a Shelly 1PM note this ID for later - save - re-check the settings!

  19. WLAN Client setup goto "Internet & Security" -> "WIFI MODE - CLIENT" Set WLAN Credentials

  20. Configure Diflouroborane Open the file "bffh.dhall" in the GUI Editor (just by double-clicking it) Change Shelly_123 to your Shelly name, e.g. shelly1-123456789ABC (case sensitive!, dash sensitive!) in "Link up machines to actors" and in "actors". Change the third IP-adress under "listens" to the IP-adress of your computer. - save

  21. start Diflouroburane change to the directory in the console where you checked for the ip-address cd BFFH/bffh/target/release load settings to Diflouroborane: ./diflouroborane -c examples/bffh.dhall --load examples start Diflouroborane: ./diflouroborane -c examples/bffh.dhall

Important every time you change the bffh.dhal you need to reload the settings (otherwise the App will not connect to the server on restart): ./diflouroborane -c examples/bffh.dhall --load examples and restart start Diflouroborane: ./diflouroborane -c examples/bffh.dhall

Download the borepin APP as described previously

To connect to the demo instance

Have fun and give feedback!

22.11.2021 // Prioritäten

30.09.2021 // Config Docs

BFFH uses DHALL for Config-File structure BFFH uses RBAC for access control

General BFFH Config

General BFFH Config is in bffh.dhall file.

listens

Contains the Addresses BFFH is listen for Connection for the API Default Port for BFFH is 59661

Example:

listens = 
[ 
    { address = "127.0.0.1", port = Some 59661 }
]

mqtt_url

Contains the Address for the MQTT Server BFFH connects to Example:

mqtt_url = "tcp://localhost:1883"

db_path

Contains the Path for the internal Database BFFH uses. BFFH will create two files: <db_path> and <db_path>-lock. Make sure that BFFH has write access in the relevant directory Example:

db_path = "/tmp/bffh"

Permissions

BFFH uses a Path-style string as permission format, separated by ".". So for example this.is.a.permission consists of the parts this, is, a and permission. When requireing permissions, such as in machines you always need to give an exact permission, so for example test.write. When granting permissions, such as in roles you can either give an exact permission or you can use the two wildcards * and +. These wildcards behave similar to regex or bash wildcards:

Wildcards are probably most useful if you group you machines around them, e.g. your 3D-printers and your one bandsaw require:

  1. Write permissions
    • machines.printers.write.prusa.sl1
    • machines.printers.write.prusa.i3
    • machines.printers.write.anycubic
    • machines.bandsaws.write.bandsaw1
  2. Manage permissions
    • machines.printers.manage.prusa.sl1
    • machines.printers.manage.prusa.i3
    • machines.printers.manage.anycubic
    • machines.bandsaws.manage.bandsaw1
  3. Admin permissions
    • machines.printers
      • For all printers
    • machines.bandsaws
      • For all bandsaws

And you then give roles permissions like so:

This way if you buy a different anycubic and split the permissions to e.g.

It still works out.

Machine Config

Machine Config is in machine.dhall file.

machines

Contains list of machines

Machines have different perission levels to interact with:

Example:

machines = 
{ 
    Testmachine = 
    { 
        name = "Testmachine",
        description = Some "A test machine",
        disclose = "lab.test.read",
        read = "lab.test.read",
        write = "lab.test.write",
        manage = "lab.test.admin"
    }
}

Roles Config

Roles Config is in roles.dhall file.

roles

Contains list of roles

Roles have a list of permission and can be inherited. Permission can be wildcard in permission list.

Example:

roles =
{
    testrole = 
    {
        permissions = [ "lab.test.*" ]
    },
    somerole =
    { 
        parents = ["testparent"],
        permissions = [ "lab.some.admin" ]
    }, 
    testparent =
    {
        permissions =
        [
            "lab.some.write",
            "lab.some.read",
            "lab.some.disclose"
        ]
    }
}

Actors Config

Actors Config is in actors.dhall file.

actors

Contains list of actors Actors are defined by a module and one or more paramters

Currenty supported actors: Shelly Parameters: id = ID of the Shelly

Process Parameters: cmd = Path of executable args = Arguments for executable

Example:

actors = 
{
    Shelly_1234 = { module = "Shelly", params = 
    {
        id = "12345"
    }},
    Bash = { module = "Process", params =
    { 
        cmd = "./examples/actor.sh",
        args = "your ad could be here"
    }}
}

actor_connections

Connects the actor with a machine A machine can have multiple actors Example:

actor_connections = 
[
    { _1 = "Testmachine", _2 = "Shelly_1234" },
    { _1 = "Another", _2 = "Bash" },
    { _1 = "Yetmore", _2 = "Bash2" }
]

26.09.2021 // CI Docs

Build Servers

Public Servers

3 Public Build Servers

Can run on any branch Only contains build tools Never contains credentials

Running on V-Servers on a public Root-Server

Internal Servers

3 Internal Build Servers

Used for Signing and Deployment Signing Key are local on the Internal Build Servers Only run on CD Branches Protected Enviroments Manual Rollouts

CD Docs

Borepin and BFFH are deployed in 3 stages

Internal(innov) Stage

Tag Borepin: alpha Tag BFFH: alphav0.1.0-

Borepin deploys to "FabAccess Testing - Intern and Beta" BFFH deploys to docker-tag "internal"

Versionnumber is JobID

Internal is only for "InnovisionLab"

Foo builds

Tag BFFH: v0\.[0-9]+\.[0-9]+

letzte alpha: v0.N.M

Bar builds

Tag BFFH: v0.X.Y X > N

Test builds

Tag BFFH: v0.X.Y+1-<git tag>

Stable release

Tag BFFH: v1.0.0

Beta Stage

Branche Borepin: beta Branche BFFH: beta

Borepin deploys to "FabAccess - Beta" BFFH deploys to docker-tag "beta"

Versionnumber is JobID

Beta is for external Testers

Production Stage

Branche Borepin: main Branche BFFH: main

Borepin deploys to "FabAccess - Production" BFFH deploys to docker-tag "latest"

Versionnumber is Git-Tag

Production is for all Users

25.09.2021 // Drehstrom Schalter

Leistungsbeschreibung

max. 16A 3 Phasen

Einkaufsliste

1x ABB ESB 24-40 1x Shelly 1 1x OBO BETTERMANN 2007734 2x Kabelverschraubung M20 - Bsp.: LAPP 53111420 1x PHOENIX CONTACT ST 2,5 BL 3x PHOENIX CONTACT ST 2,5 GR 1x PHOENIX CONTACT ST 2,5 PE 1x PHOENIX CONTACT ST D2,5 1x PHOENIX CONTACT FBS 2-5

1x IDEC YW1L-MF2E10QM3S 1x IDEC YW1P-1BUQM3G 1x IDEC YW1K-2AE10

??x Aderendhülse isoliert 2,5mm2 ??x Aderendhülse isoliert doppelt 2,5mm2 0.5m TITANEX H07RN-F 5G2,5mm2 - Zum Klemmenanschließen

Leitungslänge an Bedarf anpassen: 2m TITANEX H07RN-F 5G2,5mm2

optional für Stecker-Kupplung: 1x MENNEKES 13510 1x MENNEKES 14510

Werkzeuge

Schraubendreher - Schlitz 0,6mm x 3,5mm Schraubendreher - Schlitz 5mm Schraubendreher - PH1 Abmantelungswerkzeug Abisolierwerkzeug Crimpzange - Aderendhülsen Stufenbohrer 20-22mm

Kosten

ca. 80 €

20.03.2022 // Design Decisions NFC Reader

Design Decisions NFC Reader

Bauteile:

Version Battery:

Version PoE:

NFC IC:

IC LPCD Current Verfügbarkeit Preis MOQ
MFRC522 x 150 (Mouser) 5,85 € 1
TRF7963A x 381 (Mouser) 4,53 € 1
TRF7970A x 5.888 (Mouser) 4,95 € 1
ST25R3911B 3.6 - 8 uA 0 5.910 € - 4.098 € 1
CLRC663
PN5190 Text Text

22.09.2021 // FabAccess Workshop

Basic Information

PI

Password: password

WLAN

SSID: fabaccess_workshop Password: ?fabinfra!

Shelly

IP: 192.168.33.1

PI Preparing

# update pi
sudo apt update && sudo apt upgrade

# install docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker pi
sudo pip3 install docker-compose
reboot

Install BFFH

# clone example repo
git clone https://gitlab.com/fabinfra/fabaccess/dockercompose.git ~/fabaccess_dockercompose

Start BFFH

cd ~/fabaccess_dockercompose
docker-compose up

BFFH Config Dateien

nano config/bffh.dhall
nano config/roles.toml
nano config/user.toml

Shelly Config

MQTT Client
Internet & Security -> Advanced - Developer Settings
Enable MQTT
IP Address = Pi IP
Set MQTT Credentials

Wlan Client
Internet & Security -> WIFI MODE - CLIENT
Set WLAN Credentials

20.09.2021 // Workshop Beschaffungsliste

5 fach Schukosteckdosen

11.09.2021 // Drehstrom Schalter und Strommessung

Leistungsbeschreibung

max. 16A

Einkaufsliste

1x ABB ESB 24-40 1x Shelly 3EM 1x OBO BETTERMANN 2007734 2x Kabelverschraubung M20 - Bsp.: LAPP 53111420 1x PHOENIX CONTACT ST 2,5 BL 3x PHOENIX CONTACT ST 2,5 GR 1x PHOENIX CONTACT ST 2,5 PE 1x PHOENIX CONTACT ST D2,5 1x PHOENIX CONTACT FBS 2-5 1x RS PRO 188-1141 1x RS PRO 188-1170 1x RS PRO 188-1193 1x RS PRO 763-7949

??x Aderendhülse isoliert 2,5mm2 ??x Aderendhülse isoliert doppelt 2,5mm2 0.5m TITANEX H07RN-F 5G2,5mm2 - Zum Klemmenanschließen

Leitungslänge an Bedarf anpassen: 2m TITANEX H07RN-F 5G2,5mm2

optional für Stecker-Kupplung: 1x MENNEKES 13510 1x MENNEKES 14510

Werkzeuge

Schraubendreher - Schlitz 0,6mm x 3,5mm Schraubendreher - Schlitz 5mm Schraubendreher - PH1 Abmantelungswerkzeug Abisolierwerkzeug Crimpzange - Aderendhülsen Stufenbohrer 20-22mm

Kosten

ca. 160 €

30.08.2021 // Informationsangebot

Folgenden Leistungen erwarten wir:

15.07.2021 - Meta-Pad Zugangskontrollsysteme f. Offene Werkstätten


Meta-Pad Zugangskontrollsysteme f. Offene Werkstätten

Hier entsteht ein Zugangssystem, das, basierend auf den verschiedenen Ansätzen und gemachten Erfahrungen verschiedener Offener Werkstätten, eine möglichst breite Nutzbarkeit ermöglichen soll und Open Source ist. Ziel ist die Entwicklung möglichst objektbasierter und generischer Schnittstellen, die die diversen Bedürfnisse der Werkstätten abdecken und bestehende Systeme integrieren.

Parallel werden bereits bestehende Systeme gesammelt und ein Überblick über diese Systeme erstellt, um die daraus gewonnenen Erkenntnisse sinnvoll in das entstehende System einfließen zu lassen.

 

 

Timeline - Entwurf

Anforderungsliste / Ziele / Funktionen

Das (ideale) System soll…

Das System muss modular aufgebaut und flexibel (einfach!) einricht- anpass- und erweiterbar sein, um auf lokal verschiedene Anforderungen eingehen zu können.

Bereits laufende Aktivitäten

an Hochschulen

Fab Lab Siegen (David Amend)

BHT Berlin

qrhello (niedrigschwelliges, einfach zu “überlistendes” QR-Code-System)

Keine Einrichtung von einzelnen Maschinen notwendig - Etikett ausdrucken, draufkleben - that’s it.
Die Nummerierung und Bezeichnung der Maschinen wird (falls dort hinterlegt) aus Leihs übernommen.
Aktuell keine Logik für Zugangskontrolle und / oder Maschinenschaltung integriert.

card2go (RFID-gesichertes System mit Datenbank-Backend)

Diflouroborane (Konzeptprototyp fuer ein von Anfang an fuer weiten Einsatz gebautes System)

Stukturkonzept:Konzept.png


Kurzbeschreibung in Fliesstext Stichpunkten:

Das System ist ein frueher Prototyp und noch stark in Flux, deswegen sei fuer genauere Architektonische Details so wie den Code derzeit auf GitHub verwiesen.

RFID-Terminal

Kleiner Prototyp als Kombination verschiedener Gieß-Materialien und -Verfahren (Epoxid, PU, Acryl).
Display eingebettet, RFID-Spule eingebettet, Formteil für RFID-Karten & Fobs als negativ-Gießteil.

Verbesserungsfähiger Demonstrator / Mock-Up bei Tasso --> wer’s weiterentwickeln will, kann vorbei kommen und übernehmen.

ESP-Schütz

Für Drehstrom-Maschinen (Drehbank / Fräsen / …)
Kleine Ergänzungs-Platine, auf oder neben Schütz montierbar.
Bekommt Kommandos über WLAN und MQTT (z.B. aus OpenHab)
Schaltet die Schütz-Spule über ein SolidStateRelay (z.B. Panasonic AQH2213).
Das Schütz wiederum schaltet die Stromzufuhr zur Maschine.
Wichtig: Wiederanlaufschutz direkt an der Maschine vorsehen! - nicht “einfach so mal schnell” ein Schütz reinklemmen. Andernfalls kann schnell mal eine Drehbank “remote” eingeschaltet werden, an die sich jemand gerade “nur mal angelehnt” hatte --> wär blöd!
Auch nichts für “Niedervolt”-Anwender! - aktuell als Eingriff in die Zuleitung zur Maschine realisiert und damit hart am Regelungsbereich der Maschinenrichtilinie. Als Lösung evtl. als “Zwischen-Schaltgerät”, in jedem Fall aber Netzspannung und nur was für “VDE-Kundige” bzw. mit einiger Aufmerksamkeit anzugehen.

Mock-up existiert bei Tasso an der Drehbank --> wer’s weiterentwickeln will, kann vorbei kommen und übernehmen.

Düsseldorf (Fabian Meyer)

Kunsthochschule Halle

ETH Zürich

acos: https://sph.ethz.ch/acos_project/

In Offenen Werkstätten

https://cowiki.offene-werkstaetten.org/uploads/2017-06-23_11-31-15_Zugangssysteme Überblick (WS).pdf

FabLab L’Aquila

https://github.com/FabLabAQ/LabAccessControl

Google makerspace-auth

Dresden (Roseguarden)

Neue Version in Entwicklung seit 01/2019

München (FabLab)

MakerSpace Graz (“LEASIE”)

Zitat: "Grundidee/Basistechnologie:

Jedes zu vermietende Gerät wird mit einem IOT Gerät, basierend auf Open-Hardware, ausgestattet, dass über WLAN direkt oder indirekt über einen Cloudserver (aktuell) mit der Blockchain kommuniziert. Diese IOT Geräte regeln den Zugang und messen mit unterschiedlichen Sensoren (aktuell Strom) den Zustand des Gerätes. Zwei Varianten: Eine simple „Zwischenstecker“ Lösung und eine erweiterte (aktuell) Variante für größere Maschinen. Beispiel Lasercutter: Es wird das Gerät nicht abrupt abgeschalten, sondern zuerst der Laser. Der Zugang wird über RFID Tags (aktuell) oder NFC (Handy) überprüft. Der Server ist ein Full Node und macht die Kommunikation mit der Blockchain sowie die Abrechnung. Abgerechnet wird 2 stufig: 1 Rechnung geht vom Provider (der der den Platz für die Vermietung stellt) an den Kunden. Eine 2te Rechnung wird für den Maschinenbesitzer an den Provider ausgestellt. Provider erhält eine Fee, Auch wird in eine gemeinsame Maschinenbruchversicherung eingezahlt. Vision: Wenn zB. viele FabLabs oder MakerSpaces an dem System hängen würden, wäre das ein brauchbarer Versicherungstopf. Dapp läuft Clientseitig und erledigt den Zahlungsverkehr, die Vermietung, die Stornierung und die Fehlermeldungen. Später soll noch eine Admin DApp geben, die die Kundenanlage, Maschinenanlage und Fehlermeldungen behandeln kann 2 Smart Contracts: 1 Renting und ein Invoice Contract. Möglichkeit einen eigenen gemeinsamen Tokens, ähnlich eines Gutscheinssystem mit Insentivemöglichkeiten zu verwenden (aktuell) oder an einen Token mit z.B. Eurobindung anzuhängen. Wenn der nächste Mieter keinen Fehler meldet, rechnet das System die tatsächlich verwendete Zeit und Strom ab und überweist den Diffbetrag inkl. Kaution retour. Bei Fehlermeldung wird die Kaution eingefroren, bis der Provider den Fehler mit dem Maschinenbesitzer klärt und die Fehlerkosten erhebt. Gleichzeitig wird die Maschine auch für weitere Buchungen gesperrt. Weitere geplante größere ToDo’s: Admin DApp, DATEV Schnittstelle zur direkten Verbuchung der Rechnungen (Buchhaltung) Ergänzend: Grundsätzlich geht es nicht nur um Maschinen, sondern generell um Ressourcen. z.b. wird darüber auch der Zugang zu den Räumlichkeiten freigeschalten. Weiterer grösser angedachter Entwicklungschritt: diese Ressourcen handelbar machen und eine allgemeine Cloud Plattform dafür zur Verfügung zu stellen (Bsp. Nachbar vermietet Rasenmäher). Ergänzend zum Ressourcenhandel: Wenn du die Ressource gemietet hast und jemand anderer sie dringender braucht, sollte sie dir automatisch zu einem höheren Preis abkaufbar sein. Generell: Für FabLabs, MakerSpaces sollte dieses ganze Konzept völlig OpenSource sein. Jeder soll sich z.B. frei entscheiden können, ob er einen eigenen Token auflegt oder die Vorteile des gemeinsamen Tokens nutzen will. Auch ob er die Hardware selbst bastelt (OpenHardware) etc. Umsatz soll über einen Shop und einem Cloudservice gemacht werden. Jedoch vorrangig über Eröffnung neuer Kundenkanäle wie z.b. Gewerbekunden oder auch Privatkunden über ein Portal, sowie professional Features wie Buchhaltungsschnittstellen, etc."

Capstone (ergänzt am 29.11.2019)

In Hackerspaces

LgHS (Liege Hackerspace, Belgien) (ergänzt am 29.11.2019)

Flipdot e.V. Kassel (ergänzt am 29.11.2019)

TH Köln

Frankreich

Italien

Coredump (Hackerspace Rapperswil-Jona, Schweiz) (ergänzt am 26.06.2020)

[Projektbeschreibung - MakeThings - Zugangs- & Verwaltungstool für Spaces]

Alternativen

FabMan (https://fabman.io/)

open-taffeta

Offener Türöffner mit mobile app. Ausgelegt um an Gegensprechanlagen den Türöffner auszulösen und ein Klingeln zu verhindern wenn man sich selbst reinlässt.

Commons Booking

Verleihsystem für Lastenräder.

Brainstorming - Pad(s) / Arbeitspads

https://hazeco.re/codimd/7HkCBkSBRG6sYvT65wMPFg#
[OpenAccess Sytem Dokument zum Verbundstreffen]
[Mumble 26.11.19]
[Roseguarden]
[DiFlourBorane]
[Dudle für Sprachkonferenz 2]
[Agenda 09.12.2019]
[Protokoll 09.12.2019]
[Materialsammlung 29.12.2019 @36C3]
[Hackathon am 06.02.2020]
[Jitsi-Call am 18.02.2020]
[Diskussion in der Telegram-Gruppe des VoW am 25.02.]
[Treffen in der BHT am 04.03.2020]
[Call zu Werkstatt-Zugangssystemen (Schweiz) am 24.06.2020]
[Juli-Call Nr. 1]
[August Nr. 1]

30.06.2021 // Interfacer Deliverables

stable API for UI (Capn Proto) - Q3 2021

Update main API for controlling of the server, so the Client App can retrieve and display all required information.

OpenHardware SmartCard Initiator - Q4 2021

Release first OpenHardware Version of an OpenSource SmartCard System to activate machines.

Simple deployment method - Q4 2021

Add documentation and processes so that FabAccess can be easily deployed by non-technical users at local spaces and fablabs. Concentrate on documentation of the existing software stack and the setup process.

Audit-Log - Q4 2021

Output a structured log with the activity information about the machines, like who has when used this machine. So an ERP System can create an invoice from that data.

Basic UI - Q4 2021

Release a Beta Version of the UI with basic support of all features of the API

Federation - Q1 2022

Allow users to freely and seamlessly change their workspace between federated spaces

Scripting API - Q1 2022

Internal flows can be customised and extended in a scripting language like Python or Lua

Beta-Release - Q1 2022

Release a Beta Version of FabAccess

Branding and Templating UI - Q2 2022

Allow and help spaces and organisations to create a UI Version with specific customization for their applications

Maschinen Metadaten für erweiterte Umgebungen - Q3 2022

Allows filling machines representation with additional metadata, e.g. GPS data in the case of mobile machines.

extended monitoring and display of maschine parameters - Q4 2022

Support showing of machine metadata, with specific emphasis for branding and templating support so that different organizations can show different metadata as it suits their needs.

Optimisation and stabilty improvements of server and client in perpartation of completion of the funding phase - Q1 2023

Ensure that FabAccess will be usable beyond the timespan of the funding. Optimizing speed of all software involved and improving the stability in terms of software bugs and crashes to make use of FabAccess in production environments feasible.

29.04.2021 // Netzwerkabend Offene Werkstätten 04

06.04.2021 // Produkte für FabAccess

Die Produkte dürfen frei Verwendet werden und auch selber gedruckt werden. Wir stellen die Designs zur Verfügung, damit wir eine möglichst Hohe Wiedererkennung des Systems "FabAccess" erzeugen können. So können Nutzer das System auch in einem anderen FabLab erkennen.

Wir könnten dafür auch einen Shop aufmachen, in dem ein Obolus an die Entwickler geht und eine Finanzierung des Projekts erzeugt werden kann.

Style Guide

Farben

Primär

RGB: #00d4aa C: 68,27% M: 00,00% Y: 47,93% K: 00,00%

Sekundär

RGB: #3c474d C: 73,04% M: 55,09% Y: 49,02% K: 47,64%

Tertiär

RGB: C:

Schrift

Roboto

Print Produkte

Eingangsplakat

Das Eingangsplakat soll es Nutzern ermöglichen schnell die Domain des Space herrauszufinden. Inhalt NFC Tag - Spaceinformationen QR Code - Spaceinformationen Name das FabLabs

Maschinenaufkleber - Klein

A7

Readeraufkleber

A6

Elekrische Produkte

31.03.2021 // 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.

19.02.2021 // Demoweek Webseitentext - Korrektur

tags: DemoWeek

FabAccess Projekt Thumbnail

Das Projekt

Wir entwickeln FabAccess, ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden, um so Unfälle zu vermeiden.

Das Team

TODO: Teammitglieder verstellen

Das Problem

Viele Hacker und Maker haben sich schon mit der Herausforderung befasst, ein eigenes FabLab nach den Vorstellungen von Neil Gershenfeld aufzubauen und dieses mit wenig Personal "sicher" zu betreiben. Um das möglich zumachen, haben diese auch angefangen eine Verwaltungssoftware für ihre eigenen Spaces zu schreiben. Auch wir standen vor dieser Herausforderung: Wie kann man "gefährliche" Maschinen, wie unsere alte Drehbank, sicher betreiben? Gleichzeitig sollte natürlich die Idee des eigenständigen Lernens im FabLab erhalten bleiben, ohne dass ständig 20 Angestellte allen Nutzer:innen beim Umgang mit solchen Maschinen über die Schulter schauen müssen. Somit war die Idee für unser Projekt FabAccess geboren.

Aber das ist noch nicht alles, was FabAccess ausmacht. Aufgrund des sehr begrenzten Platzes in unserem Labor ist es uns nicht möglich, unseren Nutzer:innen jede Maschine zur Verfügung zu stellen. Wie können wir es unseren Nutzer:innen also ermöglichen, unkompliziert an andere Maschinen zu kommen, ohne unnötigen Mehraufwand bei kooperierenden Spaces zu erzeugen? Mit diesem Problem ergibt sich der zweite wichtige Aspekt von FabAccess: Es ist auch ein föderierbares Verwaltungssystem. Somit können sich Spaces aller Art zusammenschließen und die Nutzer:innen je nach Makerproblem den passenden Space besuchen. So wird die Kommunikation und Zusammenarbeit zwischen allen gestärkt. Aus Kommunikation entsteht bekanntlich Innovation.

Die Ausgangslage

Da wir Kommunikation fördern wollen, haben wir zu Beginn des Projektes auch genau dort angefangen. Um möglichst allen Bedürfnissen und Wünschen, die aus vielen Perspektiven an ein solches Verwaltungssystem gestellt werden, gerecht zu werden, haben wir uns auf FabLab- und Makerkonferenzen umgehört und sind aktiv auf die verschiedensten Creator (Nutzer:innen eines Spaces) und Manager (Betreiber:innen) solcher Spaces zugegangen. Mit diesen haben wir uns in kleinen und mittleren Runden zusammengesetzt, um alle Ideen zusammenzuschreiben.

Natürlich dachten wir uns schon, dass wir nicht die Ersten sind, die sich an ein solches Projekt wagen. Daher haben wir nach guter OpenSource-Arbeitsweise, nach eben solchen Projekten gesucht, gefragt und sind auch dort aktiv auf die Beteiligten zugegangen. Die Projekte waren auf den verschiedenesten Ständen, von einfachen Frontend-Designs bis hin zu lokal verwendeten Systemen. Um nicht auf dem Stand von "works for me" zu bleiben, haben wir uns mit den Entwickler:innen solcher Systeme getroffen und uns über die Umsetzung und "Lessons Learned" unterhalten, gechattet und offen diskutiert.

Die vielen Anregungen aus diesen Runden haben wir in einem Lastenheft kondensiert und festgehalten. Dieses Lastenheft bildet die Grundlage für unser Projekt, auch wenn wir in unserer Arbeitsweise nicht im klassischen Wasserfallmodell geblieben sind. Selbstverständlich haben wir flexibel und teilweise mit agilen Konzepten gearbeitet.

Da all diese Projekte nur lokal im Einsatz waren und wir einen föderativen Ansatz verfolgten (der "Verband offener Werkstätten" war an diesem Wunsch nicht ganz unbeteiligt), mussten wir dort gezielt ansetzen. Daraufhin haben wir uns auf die Förderung des Prototype Fund beworben, um uns in der Förderphase voll auf die Planung und Entwicklung dieses Projekts konzentrieren zu können.

Hier haben wir eine Liste von bekannten Projekten ähnlicher Zielrichtung zusammengefasst:

Die Umsetzung

Da wir zu unseren Features und Plänen schon ein paar kleine Vorträge gehalten haben sowie vieles auf unserer Webseite niedergeschrieben ist, verlinken wir an dieser Stelle dorthin. Schaut es euch gerne an.

FabAccess Feature Beschreibung: fab-access.org

FabAccess Feature- und Planungsvortrag vom rC3: media.ccc.de

Folien vom rC3 Vortrag: docs.google.com

tl;dr: FabAccess besitzt drei Hauptfunktionalitäten:

Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst wenn Nutzer:innen an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.

Tooling

Jedes Team braucht ein sinnvolles Tooling, die Frage ist nur, was heißt "sinnvoll"? Der Ansatz für unser Tooling basiert, wie bei den meisten Projekten, auf den vorhandenen Fähigkeiten der Entwickler:innen. Um einen möglichst stabilen Core zu entwickeln, wird unser Server in Rust entwickelt, da wir einen sehr guten Rustentwickler an Bord haben. Die Sprache ist auch gut für die Entwicklung stabiler Backends geeignet, weil viele Programmierfehler schon durch den relativ intelligenten Compiler verhindert werden.

Für das Frontend war es die "Wahl der Qual": Welche Plattformen will man unterstützen und mit welchem Framework kann man unsere Ideen überhaupt umsetzen? Unsere Wahl ist aufgrund der kurzen Förderphase auf C# mit Xamarin gefallen, da einer von uns schon etwas Erfahrung mit WPF-Entwicklung hatte und sich mit Hilfe von Xamarin ein Client gut auf fast alle Plattformen portieren lässt.

Für eine funktionierende und langfristige Föderation benötigten wir eine stabile API, über die die einzelnen Instanzen und Clients mit unserem Server(BFFH - Diflouroborane) kommunizieren können. Auch eine Abwärtskompatibilität ist sinnvoll, wenn BFFH von einzelnen Spaces auf deren Bedürfnisse angepasst werden können soll. Dabei sollte unser Referenzclient (Borepin) nicht funktionsunfähig werden. Um all dies möglich zu machen, ist unsere API in Cap'n Proto geschrieben.

Struktur von FabAccess, mit Schnittstellenaufteilung

Erweiterungen

Dieses Thema war bei Gesprächen mit den anderen Spaces immer vorne mit dabei, da keiner der Spaces seine selbst gebaute Hardware neu bauen will oder teuer eingekaufte Systeme verlieren möchte. Um das möglich zu machen, haben wir eine API geplant, die generisch genug ist, um verschiedenste Systeme anzubinden. Damit nicht jeder Space seine Hardware selbst basteln muss und damit zum Entwickeln eigener Software gezwungen wird, entwickeln wir von unserer Seite aus passende Referenzhardware, um den Einstieg zu erleichtern. Um die kommerziellen Produkte nicht außer acht zu lassen, arbeiten wir an der Einbindung der gängigsten Geräte, wie Shelly Plugs oder Systemen mit Tasmota und anderen. Somit kann sich ein Space beim Verwenden unseres Systems entweder unserer Bastelaufgabe stellen oder einen schnellen Einstieg durch gekaufte Produkte hinlegen.

Hardware

Hardware zur Anbindung an die Geräte wurde uns unter anderem von einem sehr engagierten Unterstützer zur Verfügung gestellt. Vielen Dank an dieser Stelle an Joris, der für uns den ersten Prototypen eines SmartCard-Readers entwickelt hat, der sich schon wunderbar an unsere Schnittstellen anbindet.

Drehbank mit ursprünglichem Schaltungsprototypen

Föderation

Nachdem wir die ganze Zeit von Föderation reden und schreiben, wollen wir auch die Frage klären, was Föderation für uns ist. Wir haben unseren Ansatz wie folgt definiert:

Föderation ist eine Form von Zusammenarbeit von Organisationen. Die Organisationen behalten dabei ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.

Unser gemeinsames Ziel mit FabAccess ist das niederschwellige und unkomplizierte Teilen von Nutzer:innen und somit die Verbesserung der Zusammenarbeit von Creatoren über Spacegrenzen hinweg sowie die gleichberechtigte Zusammenarbeit von Managern.

Unser Ansatz kann in der Realität wie folgt aussehen: Creator aus Space A geht zu Space B und kann dort mit der Einweisung für eine Maschine aus Space A die gleiche Maschine in Space B verwenden, ohne eine weitere Einweisung zu benötigen.

Wir haben gesammelt und wissen, was die meisten anderen Projekte machen und gemacht haben, zumindest innerhalb einer einzelnen Werkstatt. Allerdings gibt es verschiedene Dach-Organisationen, die diese Werkstätten als Verband gemeinsam vertreten. Um föderieren zu können, brauchen wir einen Standard, den alle nutzen können. Das können eine stabile API-Beschreibung und stabile Strukturen sein, die von den einzelnen Teilnehmenden abwärtskompatibel erweitert werden können, ohne dass die ursprünglich implementierte Föderation gestört wird.

Um nicht auf eine spezielle Hardware angewiesen zu sein, braucht es generische Schnittstellen, die komplexe und einfache Hardware unterstützen. Sicherheitsanforderungen sollen vorerst, so weit das geht, bei den Anwender:innen bleiben und nicht auf uns zurückfallen.

Was wir können (wollen): Ein sicheres und stabiles Berechtigungssystem bieten, das die notwendige Kommunikation realisiert und Events an generische Schnittstellen geben kann. Das System soll dabei granuliert und anwendungsorientiert Entscheidungen weitergeben. Weiterhin soll es den Anwender:innen dienen und dabei nicht in deren Prozesse eingreifen oder ihnen ungewollte Komplexität oder Strukturen aufzwingen oder gar in deren Entscheidungen einwirken.

Außerdem wollen wir, dass unter den einzelnen Instanzen gemeinsame Entscheidungen mit Föderation getroffen werden können, ohne dass die einzelnen Parteien ihre Rechte verlieren.

SmartCards

Um Maschinen sicher mit einer SmartCard aktivieren zu können und nicht nur über ein Handy oder einen PC, setzten wir auf NXP MIFARE DESFire Karten. Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Die DESFire-Karte besitzt ein Feature, mit dem eine Karte via OTA-Verfahren (Over-the-Air) direkt mit einem entfernten Server kommunizieren kann, ohne dass der Reader Schlüssel für die Karte benötigt. Der Reader übernimmt dabei nur die Rolle eines Proxys (Brücke/Vermittler). Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.

Die Herausforderungen

Auch wir standen während der Umsetzung vor einigen Herausforderungen, die Schwierigsten haben wir mal niedergeschrieben.

Aller Anfang ist schwer

Da unser Projekt viele Aspekte und eine hohe Komplexität besitzt, war das Auswählen schwierig. Wir konnten nicht direkt einzelne Features separat bauen, da der Core erst implementiert werden musste, bevor wir mit solchen Funktionalitäten beginnen konnten. Auf der Core-Seite begannen wir mit dem Aufbau eines Event-Netzwerks und der Anbindung von einem MQTT Server sowie dem Aufbau der Datenbankstrukturen. Auf der Client-Seite war die Auswahl für unabhängige Aufgaben begrenzt, da die Funktionalität im Core und über die Cap'n Proto API abgebildet wird. Daher stürzten wir uns auf die Implementierung von dem SmartCard Proof-of-Concept und der Anbindung der Cap'n Proto API.

UX und NFC

In unserem ersten Coaching mit Simply Secure stellten wir unseren ersten Designentwurf für Borepin vor. Bei diesem Gespräch wurde angesprochen, dass wir ein Wiedererkennungsmerkmal für eine NFC-Interaktion kreieren sollten, um so Nutzer:innen eine einfache Erkennung von NFC-Tags oder Karten bereitzustellen. Daraufhin ist unser Design für eine NFC-Markierung entstanden.

SmartCard und Maschinensticker im FabAccess NFC Design

Föderation und Netzwerke

Bei der Föderationsplanung und -entwicklung hatten wir ein paar ungeklärte Fragen zu beantworten. Da unser langfristiges Ziel ist, über eine Föderation auch eine Abrechnung zu ermöglichen, sollten die Föderationsabläufe sicher und nachvollziehbar für beide Parteien sein. Da Föderation für beide Seiten einen erkennbaren Vorteil mit sich bringen muss, ist unsere Planung bisher nur eine direkte Föderation zu erlauben. Somit föderieren nur Spaces miteinander, deren Manager sich kennen und zusammenarbeiten wollen. Es ist keine Netzwerkbildung möglich, bei der ein Zusammenschluss von Spaces entsteht, bei dem ein neuer Space direkt Zugriff auf alle Spaces erhält, ohne diese selbstständig und gegenseitig zu akzeptieren.

Community

Bei Thema Community und Unterstützer:innen netzwerken wir nun schon seit über zwei Jahren für diese Projektidee und haben uns auch in Laufe der Förderung um eine Veröffentlichung unserer Fortschritte bemüht.

Um unsere Kommunikation für die Entwicklung des Projekts nicht in privaten Chatgruppe zuführen, haben wir uns für die Open Source Software Zulip entschieden und sind dort für neue und alte Interessierte und Unterstützer:innen leicht erreichbar. Das Threading ist in Zulip für ein solches Projekt ideal.

Durch die Verbindung unserer Teammitglieder zum Chaosumfeld haben wir unseren ersten Vortrag beim Chaostreff Potsdam Anfang Dezember gehalten. In diesem konnten wir unser Projekt vorstellen und die ersten Erkenntnisse und Planungen vorstellen. Vielen Dank an dieser Stelle an den Chaostreff Potsdam für diese Gelegenheit.

Da es nun schon fast Tradition ist, auf dem Chaos Communication Congress eine kleine Gesprächsrunde rund um das Thema FabLab zuführen, haben wir uns für eine digitale Gesprächsrunde auf dem rC3 entschieden. Durch diesen Talk konnten wir unserem Projekt zu mehr Öffentlichkeit verhelfen. Auch die Make hat uns darauf hin in einem ihrer Online-Artikel erwähnt sowie ein Beitrag in der aktuellen Ausgabe veröffentlicht. Dieses mediale Interesse sowie die Rückmeldungen haben uns gezeigt, dass wir auf einem guten Weg sind und unser Projekt etwas verändern könnte.

Der Stand

Wie leider so oft in durchgeplanten Projekten haben wir nicht alle Ziele schon am Ende des Förderzeitraums erreicht.

Wir haben, wie ihr im Video sehen könnt, einen Prototypen, der die Maschinen einschalten kann.

Das SmartCard-System haben wir bisher nur als Code Libraries und Proof-of-Concept vorliegen, es muss noch in den Core eingearbeitet werden.

Wir haben eine erste Version der API am Anfang des Projektes definiert, welche grundlegende Funktionen beinhaltet, die wir zu diesem Zeitpunkt schon festlegen konnten. Wir arbeiten gerade an einer verbesserten Version, in die unsere jetzigen Kenntnisse und zukünftigen Wünsche einfließen, um bald einen stabilen Stand bieten zu können. Auch die einzelnen Subsysteme, die wir definiert haben, werden jetzt dort eingearbeitet.

Auf der Seite des Clients gibt es noch einige Bugs zu fixen, um unseren Cap'n Proto Code auf allen Plattformen ausführen zu können. Auch müssen wir unsere Designs noch in den Client einbauen. Das ist der nächste Schritt nach der API-Verbesserung.

Auch muss unsere komplette Planung noch genauer aufgeschrieben werden und unsere Konzeptentscheidungen festgehalten werden.

Für die Föderierbarkeit müssen noch ein paar Umsetzungsentscheidungen getroffen werden, dass wir dann auch alles in die API einfließen lassen können.

Wie ihr seht, haben wir noch einiges zu tun.

Die Zukunft

Die gute Nachricht ist: Wir machen weiter.

Wir arbeiten an einer Strategie zur weiteren Förderung unseres Föderationskonzepts, um es gemeinsam mit dem Verband offener Werkstätten und dem Fab:Universe-Netzwerk fertigstellen zu können und ab der zweiten Hälfte des Jahres ein größeres Roll-out angehen zu können.

Auch wollen wir in einem Machbarkeitstest unseren Core (BFFH) erweitern und so testen, ob wir auch andere Anwendungen wie z. B. ein Netzwerk aus Lastenfahrradverleihen mit unserem System unterstützen können. Unser offener und generischer Ansatz scheint sich auszuzahlen.

Föderationsablaufbeispiel von FabAccess/DEMOKrAtIS DEMOKrAtIS ist der Projektname des Machbarkeitsprojektes

Mit unseren Verbündeten aus der Schweiz werden wir auch weiter zusammenarbeiten und bekommen mit etwas Glück aus der Richtung auch noch zwei Entwickler:innen als Unterstützung.

Auch an der Hardwarefront wird weiter getüftelt, mit unserem Unterstützer wollen wir eine neue Version des Readers erarbeiten, die wir als OpenHardware und als Bausatz bereitstellen wollen.

Für das Abrechnungssystem sind wir noch auf der Suche nach einem Partner, mit dem wir als Open-Source-Lösung den FabLabs, Makerspaces und Hackerspaces bei der Abrechnung von Leistungen helfen können.

Wie ihr sehen könnt, haben wir noch einige Ideen und Visionen, an denen wir arbeiten können. Und wir bleiben unserem Motto vom Kick-off der Förderphase treu: "3 Billion Devices run FabAccess".

Für alle, die noch schöne Ideen für unser Projekt haben oder uns bei der Umsetzung (auch bei unseren anderen Fab... Projekten) helfen wollen, können wir nur sagen, kommt auf unser Zulip, wir machen was Schönes draus.

Ein kleines Fazit

Zum Projekt

Wir setzten mit diesem Projekt unseren Wunsch nach einer zusammenarbeitenden Open-Source-Gesellschaft um.

Wir haben mehr Zeit in einige Aufgaben gesteckt, als wir erwartet und geplant hatten. Mit den Ergebnissen können wir aber zufrieden sein. Wir sind unserem Ziel und der ursprünglichen Idee ein großes Stück näher gekommen.

Wir müssen aber auch zugeben, dass wir an unserem Teammanagment arbeiten müssen: Die nicht vollsynchrone Arbeitsweise mit nur wenigen persönlichen Treffen in der Gruppe bringt einige Schwierigkeiten mit sich und kann schnell zu Spannungen führen.

Zur Prototype-Fund-Förderung

Die Förderung durch den Prototype Fund hat unserem Projekt einen riesigen Sprung nach vorne ermöglicht. Ohne die Möglichkeit, viel Zeit in Planung und Entwicklung stecken zu können und dabei trotzdem unseren diversen finanziellen Verpflichtungen nachkommen zu können, wären wir nie in dem halben Jahr auf das Level gekommen, auf dem wir jetzt sind.

Die Organisation vom Prototype Fund ist gut, wir würden uns aber noch mehr Unterstützung bei den steuerlichen und finanziellen Aspekten der Förderung wünschen. Die Coachings waren sehr hilfreich für die Design-Entscheidungen, für die wir auch schon viel Lob bekommen haben, vielen Dank an Eileen und Simply Secure an dieser Stelle.

Da wir für unser Projekt auch Hardware benötigten, hätten wir uns über die Möglichkeit einer Föderung der Arbeit an zum Beispiel der Hardware eines SmartCard-Readers gefreut.

Wir hoffen, dass das BMBF auch in Zukunft solche Civic Tech Projekte unterstützt und so einen Startboost gibt.

Vielen Dank auch an die Teams von Prototype Fund, DLR und des BMBF für die Planung und Unterstützung im Rahmen dieser Förderung.

12.02.2021 // DemoWeek: Videoskript

tags: DemoWeek

Idee

Demo, das es geht. Alle anderen Infos sind im Blogtext oder auf unserer Webseite

Das ganze wird aus einer Persektive gedreht, in der das Team neben der Fräse steht. Alle anderen Ansichten sollen über Einblendungen erfolgen, so dass diese als kleine Unterstützung zu dem gesagtem dienen.

Ablaufplan

Aktion Kommentar
0 Vorstellung Team Vorstellung der Team Mitglieder
1 Team vor der Drehbank Vorstellung was ist FabAccess
2 Team vor der Drehbank Warum Fabaccess + Zeige gefährliche Drehbank
3 ("Eine Hand" demonstriert Drehbank einschalten)
4 Einblendung ESP Schütz Lösung ESP Schütz, nur keine Software zum Ansteueren
5 Demo App einschalten der Drehbank Auswählen der Maschine in der App und nutzten, dann Drehbank einschalten
6 Demo Shelly einschalten Lampe(Maschine) in der App auswählen und einschalten Generik erklären
7 Ausblick SmartCard (Einblendung) SmartCard und Reader einblenden, Einschalten über SmartCard möglich
8 Ausblick Föderation Nutzer aus anderen Spaces können auch dieses System nutzten ohne großen Aufwand, mit Berechtigungsteilen
9 Abspann Abspann

Texte

Aktion 0 - Vorstellung (0:00 - Start Timestamp)

Einfache kurze Vorstellung der Protagonisten und des FabInfra Teams.

Aktion 1 - Was ist FabAccess? (0:20)

FabAccess ist ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden können, um so Unfälle zu vermeiden. Das Ziel ist es, mehr Sicherheit in die Abläufe eines offen und niederschwellig gestalteten Werkstattbetriebs zu bringen.

Aktion 2 - Warum benötigt man FabAccess? (0:30)

Eine Drehbank ohne Anlaufschutz und nur mit einem einfachen Einschalter stellt ein sehr großes Sicherheitsrisiko dar. Um so uneingewiesenen Nutzern die Gefahr wegen Unwissenheit um die Drehbank gewickelt zu werden (und weitere Risiken im Werkstattbetrieb) zu ersparen benötigen Nutzer vorher eine Einweisung für Maschinen von denen auch im Normalbetrieb unvermeidbare Rest-Gefahren ausgehen. Die Maschinen sind nach einer Einweisung exakt so gefährlich wie vorher, die Nutzer kennen aber die Gefahren und können dadurch damit umgehen.

Aktion 3 - Drehbank einschalten (1:00)

Knopf zeigen (Wirklich nur eine Knopf) - Strudeleffekt (wenn's nicht Sch... aussieht)

Aktion 4 - ESP-Schütz (Historie - evtl. kürzen) (1:05)

Einschalten mit OpenHAB aus dem Büro ohne Wiederanlaufschutz .. ebenfalls riskant.

Aktion 5 - Demo Drehbank mit Wiederanlaufschutz über App einschalten (1:10)

Da FabAccess nur den Personen die berechtigt sind, also eingewiesen, erlaubt Maschinen zu benutzten, können auch nur diese Personen solche Maschinen einschalten. (Maschine in der App auswählen und auf Use klicken) -> Drehbank einschalten

Aktion 6 - Demo-Shelly einschalten (1:30)

Da FabAccess eine generische Schnittstelle bietet um solche Aktoren, wie den ESP32, anzubinden könnnen auch andere Geräte verwendet werden, wie diesen Shelly Plug hier.

Aktion 7 - SmartCard (1:50)

Um im Makeralltag nicht immer sein Handy zu benötigen, bietet FabAccess eine SmartCard-Anbindung, durch die das Einschalten der Maschinen auch mit einer DESFire Karte und einem Reader erfolgen kann. Anbindung an QR-Code-Systeme ist auch möglich.

Aktion 8 - Föderation (2:10)

Um die Zusammenarbeit von Spaces zu unterstützen und zu fördern ist FabAccess föderierbar, so können Nutzer zwischen den Spaces hin und her wechseln ohne jedes mal neu in eine Maschine eingewiesen zu werden.

Abspann (2:30)

FabInfra-Team .. und (Mention/Props für) alle die an Vor- oder Parallel-Projekten gearbeitet haben (Joris/Marcio/Kevin/Faaabi/ .. wenn sie nichts dagegen haben).

Grün: #00d4aa 0 212 170 Hintergrund: #3c474d Grau: #adadad 173 173 173

Abstann Text

Das FabAccess Team: Jannis Rieger Tasso Mulzer Kai Kriegel Gregor Reitzenstein Joseph Langosch

Besonderer Dank an unsere Unterstützer:innen für das Projekt: Joris Bijkerk Maximilian Voigt Fabian Meyer Marcus Drobisch Kevin Krechan Marcio Ferreira dos Santos Timm Wille Thee Vanichangkul MrHat2010

und an das Kamerateam: fa

(Reihenfolge ungefähr so .. oder einfach alphabetisch)

12.02.2021 // Demoweek: Webseitentext

tags: DemoWeek

Ihr veröffentlicht einen Text über das Ziel, die Entstehung und andere interessante Aspekte eures Projekts oder Erkenntnisse aus der Förderphase.

FabAccess Projekt Thumbnail

Das Projekt

Wir entwickeln FabAccess, ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden, um so Unfälle zu vermeiden.

Das Team

TODO: Teammitglieder verstellen

Das Problem

Viele Hacker und Maker haben sich schon mit der Herausforderung befasst ein eigenes FabLab nach den Vorstellungen von Neil Gershenfeld aufzubauen und dieses mit wenig Personal "sicher" zu betreiben. Um das möglich zumachen haben diese auch angefangen eine Verwaltungssoftware für ihre eigenen Spaces zu schreiben. Auch wir standen vor der Herausforderung: Wie kann man "gefährliche" Maschinen, wie unsere alte Drehbank, sicher betreiben? Gleichzeitig sollte natürlich die Idee des eigenständigen Lernens im FabLab erhalten bleiben, ohne dass ständig 20 Angestellte Jedem beim Umgang mit solchen Maschinen über die Schulter schauen müssen. Somit war die Idee für unsere Projekt FabAccess geboren.

Aber das ist noch nicht alles was FabAccess ausmacht. Durch den doch sehr begrenzten Platz in unserem Labor ist es uns nicht möglich jede Maschine unseren Nutzern zur Verfügung stellen zu können. Wie können wir es also unseren Nutzern ermöglichen, unkompliziert an andere Maschinen zu kommen und gleichzeitig so wenig wie möglich Mehraufwand bei kooperierenden Spaces zu erzeugen. Mit diesem Problem ergibt sich der zweite wichtige Aspekt von FabAccess, denn FabAccess ist ein föderierbares Verwaltungssystem. Somit können sich Spaces aller Art zusammenschließen und die Nutzer können je nach Makerproblem den passenden Space besuchen. So wird die Kommunikation und Zusammenarbeit zwischen allen gestärkt. Aus Kommunikation entsteht bekanntlich Innovation.

Die Ausgangslage

Da wir Kommunikation fördern wollen, haben wir zu Beginn des Projektes auch genau dort angefangen. Um möglichst allen Bedürfnissen und Wünschen, die aus vielen Perspektiven an ein solches Verwaltungssystem gestellt werden, gerecht zu werden, haben wir uns auf FabLab- und Makerkonferenzen umgehört und sind aktiv auf die verschiedensten Creator(Nutzer eines Spaces) und Manager(Betreiber eines Spaces) solcher Spaces zugegangen. Mit diesen gemeinsam haben wir uns in kleinen und mittleren Runden zusammengesetzt, um all die Ideen zusammenzuschreiben.

Natürlich dachten wir uns schon, dass wir nicht die Ersten sind, die sich an ein solches Projekt wagen. Daher haben wir nach guter OpenSource-Arbeitsweise, nach solchen Projekten gesucht, gefragt und sind auch dort aktiv auf die Beteiligten zugegangen. Die Projekte waren auf den verschiedenesten Ständen, von einfachen Frontend-Designs bis hin zu lokal verwendeten Systemen. Um nicht auf dem Stand von "works for me" zu bleiben, haben wir uns mit den Entwicklern solcher Systeme getroffen und uns über die Umsetzung und "Lessons Learned" unterhalten, gechattet, gemeetet und offen diskutiert.

Die vielen Anregungen aus diesen Runden haben wir in einem Lastenheft kondensiert und festgehalten. Dieses Lastenheft bildet die Grundlage für unser Projekt, auch wenn wir in unserer Arbeitsweise nicht im klassischen Wasserfallmodell geblieben sind. Selbstverständlich haben wir flexibel und teilweise mit agilen Konzepten gearbeitet haben.

Da all diese Projekte nur lokal im Einsatz waren und wir einen föderativen Ansatz verfolgten (der "Verband offener Werkstätten" war an diesem Wunsch nicht ganz unbeteiligt) mussten wir dort gezielt ansetzen. Daraufhin haben wir uns auf die Förderung des Prototype Fund beworben, um uns in der Förderphase voll auf die Planung und Entwicklung dieses Projekts konzentrieren zu können.

Liste von bekannten Projekten ähnlicher Zielrichtung:

Die Umsetzung

Da wir zu unseren Features und Plänen schon ein paar kleine Vorträge gehalten haben, sowie vieles auf unserer Webseite niedergeschrieben ist, verlinken wir an dieser Stelle dorthin. Schaut es euch gerne an.

FabAccess Feature Beschreibung: fab-access.org

FabAccess Feature- und Planungsvortrag vom rC3: media.ccc.de

Folien vom rC3 Vortrag: docs.google.com

tl;dr: FabAccess besitzt drei Hauptfunktionalitäten:

Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst wenn Nutzer an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.

Warning Wir werden in dem weiteren Text mehr auf die Projektumsetzung und die Prototype Fund Förderung eingehen, da wir die Features schon ausführlicher und besser in den Beiträgen erklärt haben.

Tooling

Jedes Team braucht ein sinnvolles Tooling, die Frage ist nur, was heißt "sinnvoll"? (yeah!! - Tooldiskussionen!!) Der Ansatz für unser Tooling basiert, wie bei den meisten Projekten, auf den vorhandenen Fähigkeiten der Entwickler. Um einen möglichst stabilen Core zu entwickeln wird unsere Server in Rust entwickelt, da wir einen sehr guten Rustentwickler an Bord haben. Die Sprache ist auch gut für die Entwicklung stabiler Backends geeignet, weil viele Programmierfehler schon durch den relativ intelligenten Compiler verhindert werden.

Für das Frontend war es die "Wahl der Qual", welche Plattformen will man unterstützen und mit welchem Framework kann man unsere Ideen überhaupt umsetzen. Unsere Wahl ist aufgrund der kurzen Förderphase auf C# mit Xamarin gefallen, da einer von uns schon etwas Erfahrung mit WPF-Entwicklung hatte und sich mit Hilfe von Xamarin ein Client gut auf fast alle Plattformen portieren lässt.

Für eine funktionierende und langfristige Föderation benötigten wir eine stabile API, über die die einzelnen Instanzen und Clients mit unserem Server(BFFH - Diflouroborane) kommunizieren können. Auch eine Abwärtskompatibilität ist sinnvoll, wenn BFFH von einzelnen Spaces auf deren Bedürfnisse angepasst werden können soll. Dabei sollte unser Referenzclient (Borepin) nicht funktionsunfähig werden. Um all dies möglich zu machen, ist unsere API in Cap'n Proto geschrieben.

Struktur von FabAccess, mit Schnittstellenaufteilung

Erweiterungen

Dieses Thema war bei Gesprächen mit den anderen Spaces immer vorne mit dabei, da keiner der Spaces seine selbst gebaute Hardware neu bauen will oder teuer eingekaufte Systeme verlieren möchte. Um das möglich zu machen, haben wir eine API geplant, die generisch genug ist um verschiedenste Systeme anzubinden. Damit nicht jeder Space seine Hardware selbst basteln muss und damit zum Entwickeln eigener Software gezwungen wird, entwickeln wir von unserer Seite aus passende Referenzhardware um den Einstig zu erleichtern. Um die kommerziellen Produkte nicht außer Acht zu lassen, arbeiten wir an der Einbindung der gängigsten Geräte, wie Shelly Plugs oder Systeme mit Tasmota und anderen. Somit kann sich ein Space beim Verwenden unseres Systems entweder unserer Bastelaufgabe stellen oder einen schnellen Einstieg durch gekaufte Produkte hinlegen.

Hardware

An der Hardware haben wir durch die Bindung der Förderung leider nicht so viel arbeiten können, aber wir haben einen sehr engagierten Unterstützter gefunden (Vielen Dank an dieser Stelle an Joris), der für uns den ersten Prototypen eines SmartCard-Readers entwickelt hat, der sich schon wunderbar an unsere Schnittstellen anbindet. Für weitere Hardware zum Schalten haben wir schon vor der Förderphase eine Gruppe aus der Schweiz gefunden, die mit uns bei diesem Vorhaben zusammenarbeitet.

Also erstmal noch ein kleines "coming soon".

Drehbank mit erstem Schaltungsprototypen

SmartCards

Einen SmartCard-Reader benötigen wir durch den Wunsch Maschinen mit einer SmartCard zu aktivieren und nicht nur über ein Handy oder einen PC. Dieses Feature war bei der Planung nicht vollständig in seiner Komplexität zu erfassen. Es gibt einige gute Open Source Libraries, mit denen sich so gut wie alle auf dem Markt befindlichen SmartCards lesen und beschreiben lassen. Die Frage, die wir uns in diesem Zusammenhang stellen mussten war, welche der Karten unterstützen wir und was sind unsere Anforderungen an eine SmartCard. In einem anderen Projekt werden NXP MIFARE Classic Karten verwendet. Da diese schon seit über 10 Jahren keinen ernstzunehmenden Schutz mehr gegen Clonen der Karten bieten, haben wir uns gegen eine solche Lösung entschieden. Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Um das valide und nutzbar umzusetzen haben wir uns für eine kostengünstige Lösung, mit NXP Mifare DESFire Karten entschieden. Die Karte besitzt das Feature, dass sie OTA (Over-the-Air) mit entfernten Servern kommunizieren kann. Somit kann zwischen der Karte und dem Server direkt verschlüsselt kommunziert werden und der Reader spielt nur Proxy. Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.

Föderation

Nachdem wir die ganze Zeit von Föderation reden und schreiben wollen wir auch die Frage klären, was Föderation für uns ist. Wir haben unseren Ansatz wie folgt definiert:

Föderation ist eine Form von Zusammenarbeit von Organisationen. Die Organisationen behalten dabei ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.

Unser gemeinsames Ziel mit FabAccess ist das niederschwellige und unkomplizierte Teilen von Nutzern und somit die Verbesserung der Zusammenarbeit von Creatoren über Spacegrenzen hinweg, sowie die gleichberechtigte Zusammenarbeit von Managern.

Unser Ansatz kann in der Realität wie folgt aussehen: Creator aus Space A geht zu Space B und kann dort mit der Einweisung für eine Maschine aus Space A die gleiche Maschine in Space B verwenden, ohne eine weitere Einweisung zu benötigen.

Wir haben gesammelt und wissen was die meisten anderen Projekte machen und gemacht haben. Zumindest innerhalb einer einzelnen Werkstatt. Allerdings gibt es verschiedene Dach-Organisationen, die diese Werkstätten als Verband gemeinsam vertreten. Um föderieren zu können brauchen wir einen Standard, den alle nutzen können. Also eine stabile API-Beschreibung und stabile Strukturen, die von den einzelnen Teilnehmern abwärtskompatibel erweitert werden können, ohne dass die ursprünglich implementierte Föderation gestört wird.

Um nicht auf eine spezielle Hardware angewiesen zu sein braucht es generische Schnittstellen, die komplexe und einfache Hardware unterstützen. Sicherheitsanforderungen sollen vorerst so weit das geht beim Anwender bleiben und nicht auf uns zurückfallen.

Was wir können (können wollen): Ein sicheres und stabiles Berechtigungssystem bieten, das die notwendige Kommunikation realisiert und Events an generische Schnittstellen geben kann. Das System soll dabei granuliert und anwenderorientiert Entscheidungen weitergeben. Weiterhin soll es den Anwendern dienen und dabei nicht in deren Prozesse eingreifen oder ihnen ungewollte Komplexität oder Strukturen aufzwingen, oder gar in deren Entscheidungen einwirken.

Und dass unter den einzelnen Instanzen gemeinsame Entscheidungen mit Föderation getroffen werden können, ohne dass die einzelnen Parteien ihre Rechte verlieren.

Die Herausforderungen

Auch wir standen während der Umsetzung vor einigen Herausforderungen, die Schwierigsten haben wir mal niedergeschrieben.

Aller Anfang ist schwer

Da unser Projekt viele Aspekte und eine hohe Komplexität besitzt war das Auswählen schwierig. Wir konnten nicht direkt einzelene Features seperat bauen, da der Core erst implementiert werden musste, bevor wir mit solchen Funktionalitäten beginnen konnten. Auf der Core-Seite begannen wir mit dem Aufbau eines Event-Netzwerks und der Anbindung von einem MQTT Server, sowie dem Aufbau der Datenbankstrukturen. Auf der Client-Seite war die Auswahl für unabhängige Aufgaben begrenzt, da die Funktionalität im Core und über die Cap'n Proto API abgebildet wird. Daher stürzten wir uns auf die Implenetierung von dem SmartCard Proof-of-Concept und der Anbindung der Cap'n Proto API.

Closed Source SmartCards

Die Möglichkeit für ein OTA-Verfahren, mit den DESFire Karten, haben wir einem Beispiel Dokument direkt von NXP entnommen. Zum Glück hat sich ein Entwickler schon mit der Implementierung eines solchen Verfahren beschäftigt und die nötigen Schritte in ein bisschen Python Code validiert und mit einer kurzen Beschreibung auf GitHub veröffentlicht. Auf der Suche nach NFC-Libraries stellt sich eine über ein Netzwerk aufgebaute Verbindung als nicht sehr verbreitet heraus und die Libraries waren alle so aufgebaut, direkt mit der Karte über einen Reader oder die von Windows bereitgestellt PC/SC (Personal Computer/Smart Card API) zu kommunizieren. Da wir die Kommunikation mit Karte vom BFFH aus durchführen müssten wir sowohl für C# als auch für Rust eine verwendbare Bibliothek finden. Da sich keine passenden Library finden ließ, haben wir uns der Herausforderung gestellt und selber eine Klassenbibliothek in C# begonnen, die wir nach Rust porten wollten. Das stellte sich als schwerer heraus als gedacht, da die Dokumentation von der von uns verwendeten DESFire Karten unter einem NDA(Geheimhaltungsvertrag) steht und wir mit unserem Open Source Code diese Anforderungen nicht erfüllen können. An diesem Zeitpunkt begann für uns eine umfangreiche Recherche und Dokumentensammlung, wie die DESFire Karte funktioniert. Da die bekannten Libraries leider keine Kommunikationsbeispiele besitzten haben wir Tests für unsere Bibliothek aufgebaut, die genau einer reale Kommunikation mit der Karte entspricht. Mit diesen Tests können wir einfacher unseren Code in Rust testen. Wir werden unsere Unterlagen dazu nach einer Aufarbeitung auch bei uns in einem eigenen GitLab-Projekt veröffentlichen. Da wir anderen Entwicklern die Arbeit mit diesen Karten vereinfachen möchten.

UX und NFC

In unserem ersten Coaching, mit SimpleSecure stellten wir unseren ersten Designentwurf für Borepin vor. Bei diesem Gespräch stellt sich heraus, dass wir an dem Wiedererkennungsmerkmal für eine NFC Interaktion kreieren sollten, um so Nutzern eine einfache Erkennung von NFC Tags oder Karten bereitzustellen. Somit ist unser Design für eine NFC Markierung entstanden.

SmartCard und Maschinensticker im FabAccess NFC Design

Föderation und Netzwerke

Bei der Föderationsplanung und -entwicklung hatten wir ein paar ungeklärte Fragen zu beantworten. Da unser langfristiges Ziel ist über eine Föderation auch ein Abrechnung zu ermöglichen sollten die Föderationsabläufe sicher und nachvollziehbar für beide Partein sein. Da Föderation für beide Seiten ein Vorteil mit sich bringen muss, sind bisher die Planung von unserer Seite nur eine direkte Föderation zu erlauben. Somit föderieren nur Spaces miteinandern, wo sich die Manager kennen und zusammenarbeiten wollen. Es ist keine Netzwerkbildung möglich, bei der ein Zusammenschluss von Spaces entsteht, bei dem ein neuer Spaces direkt Zugriff alle Space bekommt ohne diese selbstständig und gegenseitig zu akzeptieren. Diese Entscheidung hat viele Diskussionen mit sich gebracht, da wir aber auch keine rechtliche Grundlage sehen dort Berechtigungen auszutauschen halten wir diese Vorgehenweise in der aktuellen Position für die sinnvollste. Wir wollen ja auch die Kommunikation fördern, also warum sollten die Manager denn nicht, mit einander mal geredet haben.

Community

Bei Thema Community und Unterstüzer netzwerken wir nun schon seit über zwei Jahren für diese Projektidee und haben uns auch in Laufe der Förderung, um eine Veröffentlichung unser Fortschritte bemüht.

Um unsere Kommunikation für die Entwicklung des Projekts nicht in privaten Chatgruppe zuführen haben wir uns für die Open Source Software Zulip entschieden und sind dort für neue und alte Interessierte und Unterstützer leicht erreichbar. Und das Threading ist in Zulip für ein solches Projekt ideal, um hier mal ein bisschen Werbung zumachen.

Durch die Verbindung unser Teammitglieder zum Chaosumfeld haben wir unseren ersten Vortrag beim Chaostreff Potsdam, anfang Dezember, gehalten. Das war zwar bei uns noch nicht so geplant hatte sich aber durch ein Missverständnis so ergeben. In diesem konnten wir unser Projekt vorstellen und die ersten Erkenntnisse und Planungen vorstellen. Vielen Dank an dieser Stelle an den Chaostreff Potsdam.

Da es nun schon fast Tradition ist auf dem Chaos Communication Congress eine kleine Gesprächsrunde rund um das Thema FabLab zuführen haben wir uns für eine digitale Gesprächsrunde auf dem rC3 entschieden. Durch diesen Talk konnten wir unserem Projekt zu mehr Öffentlichkeit verhelfen. Auch die Make hat uns darauf hin in einem ihrer Online Artikel erwähnt, sowie ein Beitrag in der aktuellen Ausgabe veröffentlicht. Dieses mediale Interesse, sowie die Rückmeldungen haben uns gezeigt, dass wir auf einem guten Weg sind und unser Projekt etwas verändern könnte.

Der Stand

Wie leider so oft in durchgeplanten Projekten haben wir nicht alle Ziele schon am Ende des Förderzeitraums erreicht.

Wir haben wie ihr in dem Video gesehen habt einen Prototypen der Maschinen einschalten kann.

Das SmartCard-System haben wir bisher nur als Code Libraries und Proof-of-Concept vorliegen, es muss noch in den Core eingearbeitet werden.

Wir haben eine erste Version der API am Anfang des Projektes definiert, welche grundlegende Funktionen beinhaltet hat die wir zu diesem Zeitpunkt schon festlegen konnten. Wir arbeiten gerade an einer verbesserten Version in die unsere jetzigen Kenntnisse und zukünftigen Wünsche einfließen, um bald einen stabilen Stand bieten zu können. Auch die einzelenen Subsysteme die wir definiert haben werden jetzt dort eingearbeitet.

Auf der Seite des Clients gibt es noch einige Bugs zu fixen, um unseren Cap'n Proto Code auf allen Plattformen ausführen zu können. Auch müssen wir unsere Designs noch in den Client einbauen, das ist der nächste Schritt nach der API Verbesserung.

Auch muss unsere komplette Planung noch genauer aufgeschrieben werden und unsere Konzept-Entscheidungen festgehalten werden.

Für die Föderierbarkeit müssen noch ein paar Umsetzungsentscheidungen getroffen werden, dass wir dann auch alles in die API einfließen lassen können.

Wie ihr seht haben wir noch einiges zu tun.

Die Zukunft

Die gute Nachricht ist, wir machen weiter.

Wir arbeiten an einer Strategie zur weiteren Förderung unseres Föderationskonzepts, um das gemeinsam mit dem Verband offener Werkstätten und dem Fab:Universe-Netzwerk fertigstellen zu können, um ab der zweiten Hälfte des Jahres ein größeres Rollout angehen zu können.

Auch wollen wir in einem Machbarkeitstest unseren Core (BFFH) erweitern und so testen, ob wir auch andere Anwendungen wie z.B. ein Netzwerk aus Lastenfahrradverleihen mit unserem System unterstützen können. Unser offener und generischer Ansatz scheint sich auszuzahlen.

Föderationsablaufbeispiel von FabAccess/DEMOKrAtIS DEMOKrAtIS ist der Projektname des Machbarkeitsprojektes

Mit unseren Verbündeten aus der Schweiz werden wir auch weiter zusammenarbeiten und bekommen mit etwas Glück aus der Richtung auch noch zwei Entwickler*innen als Unterstützung.

Auch an der Hardwarefront wird weiter getüftelt, mit unserem Unterstützer wollen wir eine neue Version des Readers erarbeiten, die wir als OpenHardware und als Bausatz bereitstellen wollen.

Zu dem Thema Abrechnungssystem sind wir noch auf der Suche nach einem Partner mit dem wir als Open Source Lösung den FabLabs, Makerspaces und Hackerspaces bei der Abrechnung von Leistungen helfen können.

Wie ihr sehen könnt, haben wir noch einige Ideen und Visionen, an denen wir arbeiten können. Und wir bleiben unserem Motto vom Kickoff der Förderphase treu "3 Billion Devices run FabAccess".

Für alle die noch schöne Ideen für unser Projekt haben oder uns bei der Umsetzung (auch bei unseren anderen Fab... Projekten) helfen wollen, können wir nur sagen, kommt auf unser Zulip, wir machen was Schönes draus.

Ein kleines Fazit

Vom Projekt

Wir setzten mit diesem Projekt unseren Wunsch nach einer zusammenarbeitenden Open Source Gesellschaft um.

Leider waren auch wir durch die Corona Pandemie gebremst und auch einige Projektkontakte sind im Sande verlaufen. An der Stelle: Das war in keinem Fall Absicht!! - meldet euch einfach wieder bei uns, wenn ihr Zeit und Lust habt. Wir freuen uns über jeden der mit macht. Im großen und ganzen haben wir das Beste aus der geförderten Zeit gemacht.

Wir haben mehr Zeit in einige Aufgaben gesteckt als wir erwartet und geplant hatten. Mit den Ergebnissen können wir aber zufrieden sein. Wir sind unserem Ziel und der ursprünglichen Idee ein großes Stück näher gekommen.

Wir müssen aber auch zugeben, dass wir an unserem Teammanagment arbeiten müssen, die nicht vollsynchrone Arbeitsweise mit nur wenigen persönlichen Treffen in der Gruppe bringt einige Schwierigkeiten mit sich und kann schnell zu Spannungen führen.

Von der Prototype Fund Förderung

Die Förderung durch den Protoype Fund hat unserem Projekt einen riesigen Sprung nach vorne verschafft. Ohne die Möglichkeit, viel Zeit in Planung und Entwicklung stecken zu können und dabei trotzdem unseren diversen finanziellen Verpflichtungen nachkommen zu können, wären wir nie in dem halben Jahr auf das Level gekommen, auf dem wir jetzt sind.

Die Organisation vom Prototype Fund ist gut, wir würden uns aber noch mehr Unterstützung bei den steuerlichen und finanziellen Aspekten der Förderung wünschen. Die Coachings waren sehr hilfreich für die Design Entscheidungen, für die wir auch schon viel Lob bekommen haben, vielen Dank an Eileen und Simply Secure an dieser Stelle.

Wir hoffen, dass das BMBF auch in Zukunft solche Civic Tech Projekte unterstützt und so einen Startboost gibt.

Vielen Dank auch an das Team vom Prototype Fund für die Planung und Unterstützung bei dieser Förderung.

02.02.2021 // FabAccess Struktur

Die Struktur von FabAccess soll größtmögliche Flexibilität bieten, um so den jeweiligen Anwendern die Anpassungsmöglichkeiten an deren Strukturen zu gewärleisten.

Die Erweiterbarkeit ist durch generische Schnittstellen zu weiteren Softwarepaketen und den Hardwarekomponenten gegeben und so nicht an einen Herrsteller gebunden.

Die Auswertung von Aktionen des Systems kann über eine Schnittstelle(Audit Log) erfolgen, um so eigene Software wie z.B. ein Abrechnungsystem anzubinden und den Funktionsumfang an den jeweiligen Bedarf anzupassen.

Vom Projekt her werden schon Anbindungen an übliche externe Systeme (Shelly, Tasmota, Odoo, …) bereitgestellt, um einen einfachen Einstieg zu ermöglichen. Weiterhin wird eine kuratierte Plattform zur Sammlung von solchen Schnittstellen-Software oder -Hardware zur Verfügung gestellt.

26.01.2021 // Projektskizze FabAccess IGP

tags: IGP, FabAccess

[TOC]

Allgemeines

IGP-Föderung

Innovationsprogramm für Geschäftsmodelle und Pionierlösungen

:::info https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/igp-einstieg.html :::

In der dritten Ausschreibungsrunde zu Innovationen im Bereich Bildung und Informationszugang mit hohem „sozialen Impact“ werden Ideen in den Fokus genommen, die Bildungsmöglichkeiten schaffen oder verbessern und/oder dazu beitragen, neue oder leichtere Zugänge zu Informationen zu ermöglichen. Die Projektideen sind geprägt von einem primär nichttechnischen Entwicklungscharakter, gleichwohl können neue technische Entwicklungen genutzt, adaptiert und in neue Zusammenhänge gebracht werden.

Projekt Details

https://fab-infra.org/de/projects/fabaccess/

Projekt-Antrag

Allgemeines

Projekt-Antrag

Antrag ist bis zum 2.2.2021 15 Uhr online einzureichen Dazu wird benötigt ein Teilnahmeantrag (Skizze):

Hier stehen Ihnen alle relevanten IGP-Dokumente zum Teilnahmewettbewerb der dritten Ausschreibungsrunde zur Verfügung: https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/dokumente-teilnahmewettbewerb.html

OnlineAntrag: https://www.vdivde-it.de/submission/acl_users/credentials_cookie_auth/require_login?came_from=https%3A//www.vdivde-it.de/submission/bekanntmachungen/2027/p/1983578896/logged_out die Zugangsdaten sind in der Personaldatei

Antragsfinanzierung

hier muss auch die Antragssumme errechnet werden, etc.: https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-hilfe-tool-zur-berechnung-der-voraussichtlichen-zuwendung.pdf?__blob=publicationFile&v=6 https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-hilfe-tool-zur-berechnung-von-mitarbeiter-und-umsatzzahlen.pdf?__blob=publicationFile&v=4

Online Antrag

Kurztitel

Federated:Access /F:A

Vollständiger Titel der Projektskizze

"Nutzen ist das neue Haben“ und „Teilen das neue Besitzen“ Alltagsimplementierte Kreislaufführung von Ressourcen mittels "Zugang zu.. statt Eigentum an…"

Projektform

A: Experimentelle Einzel- oder Kooperationsprojekte in der innovativen Frühphase mit dem Charakter von Machbarkeitstests

Kurzbeschreibung

1000 Zeichen

Teilen und somit nachhaltige Ressourcenschonung im Alltag zu stärken und zu etablieren ist die adressierte Herausforderung: Alle haben unzählige Güter die nur zeitweise genutzt werden. Eine Bohrmaschine z.B. wird im Schnitt pro Jahr nur eine Stunde genutzt und liegt ansonsten im Schrank. Eigentlich könnten diese Dinge auch Freunden oder Nachbarn, d.h. Anderen zur Verfügung gestellt werden. Und nicht nur private Ressourcen, sondern auch die von Organisationen und Institutionen, Unternehmen oder Einrichtungen der kommunalen Daseinsvorsorge werden nicht so genutzt, wie sie könnten. Überlassung ist an Kriterien und Bedingungen geknüpft. Beispielsweise muss die Fähigkeit zur sachkundigen Handhabung eines Dings, die Zugehörigkeit zu einer autorisierten Personengruppe oder bestehender Versicherungsschutz nachgewiesen werden, damit Zugang gewährt werden kann. Gesamtgesellschaftlich wird Zugang zu den Ressourcen, die wir teilen und damit temporär besitzen können, benötigt. F:A gewährt diesen.

Frühester Beginn

Juli 2021 (ist gesetzt)

Antragssteller

Verbund Offener Werkstätten

Andere Einrichtungen vertreten über die mitarbeitenden Personen

IGP Poster

Innovationsbedarf

max. 2.500 Zeichen inkl. Leerzeichen

Verdeutlichen Sie insbesondere, wie durch die Adressierung des Bedarfs ein „sozialer Impact“, also eine positive Wirkung für das Gemeinwohl, entstehen kann.

Wichtig ist, dass der Neuigkeitswert der Projektidee und auch das längerfristige Potenzial der Innovation gut erkennbar sind.

Bedarf fundiert begründen und nach Möglichkeit belegen.

In jedem Fall sollte deutlich werden, dass Ihre Innovation hohen Neuigkeitswert besitzt und auf eine konkrete Problemstellung, einen Nutzen für die Zielgruppe (bei uns die Gesellschaft ?), einen unbefriedigten Bedarf o. Ä. zielt. In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftliche Nachhaltigkeit und sozialer Impact bewertet.

Welchen Bedarf adressieren wir mit unserer Idee? (es geht auch um das "Heben ungenutzter Potentiale")

Warum muss es realisiert werden?

Welche Zielgruppe, welches gesellschaftlich wichtige Feld adressieren wir?

Lösungsansatz

Geschäftsidee/Pionierlösung

Die Darstellung Ihrer Geschäftsidee/Pionierlösung muss ohne weitere Quellen/Verweise/Dokumente verständlich und überzeugend sein. Quellenangaben und externe Verlinkungen können als Belege für Ihre Aussagen genannt werden, sie dürfen aber nicht für das Verständnis der Skizze essentiell sein! Beschreiben Sie,wie Ihre Geschäftsidee/Pionierlösung den Innovationsbedarf adressiert und ggf. die identifizierte Angebotslücke ausnutzt. Dabei ist es wichtig, die Idee mit ihren Stärken,Potentialen und vor allem ihrem Neuigkeitswert prägnant darzustellen. Beschreiben Sie bitte, welchen Mehrwert die von Ihnen adressierte Zielgruppe durch Ihre Pionierlösung gewinntund arbeiten Sie u.a.damit das Alleinstellungsmerkmal Ihrer Innovation heraus. Gehen Sie bitte auch auf die grundsätzliche Machbarkeit ein, und vermitteln Sie diese insbesondere für Projekte der Projektform B, z. B.durch den Verweis auf geleistete Vorarbeiten.

Umsetzung

max. 3.500 Zeichen

Wettbewerb

max. 3.000 Zeichen

Antragsstellende

Antragstellende Unternehmen und Einrichtungen

max. 2000 Zeichen

Qualifikation der vorgesehenen Mitarbeiter

Wirkungspotenzial

max. 3.000 Zeichen

Förderbedarf

max. 2.000 Zeichen

Grobstruktur

PTF rechnet mit 50€/h p.Person. 40h pro Woche, aufgeteilt auf die Leute die dabei sind. Förderung reicht dann nicht - bzw. Wochenstunden sind recht klein. --> Wochenstunden oder Honorar runter --> Laufzeit auf zB 8 Monate verkürzt: je 1 Monat Ein- & Ausstieg in/ ausm Projekt sowie 6 Monate Testphase

Wann brauchen wir die UG --> schreiben, dass wir die gründen & zur Antragsstellung tut's auch der VoW e.V.

Basis-Info-Seiten zu F:A ==> gibt es mehr Quellen ? https://fab-access.org/de/projects/fabaccess/ https://fabinfra.gitlab.io/fabaccess_lastenheft/FabAccess_Lastenheft.pdf

LoIs einholen von ? -> Nein, brauchen wir nicht jetzt.

Angaben für die Online-Abgabe:

Wir können bis zu 4 Abbildungen mit je 100 Zeichen Text beifügen. Diese Möglichkeit ist freiwillig. Zwei Abbildungen können im Abschnitt Lösungsansatz eingefügt werden.
Zwei weitere Abbildungen können am Ende des IGP-Posters eingefügt werden. Welchen Aspekt Ihrer Skizze Sie durch die Abbildungen illustrieren möchten, obliegt natürlich Ihnen.

Frühester Beginn:

Bestätigen, dass die Umsetzung noch nicht begonnen ist: Nee, weil die Machbarkeitstests noch ausstehen.

*Wir müssen ein sog. IGP-Poster ausfüllen in dem Online-Tool (Zugang siehe oben), hier die Themen die wir beantworten müssen, schreibt dazu was euch einfällt:

1. Innovationsbedarf - max. 2.500 Zeichen inkl. Leerzeichen.

welchen Bedarf adressieren wir mit unserer Idee ? (es geht auch um das "Heben ungenutzter Potentiale")

Warum muss es realisiert werden ?

Welche Zielgruppe, welches gesellschaftlich wichtige Feld adressieren wir ?

Verdeutlichen Sie insbesondere, wie durch die Adressierung des Bedarfs ein „sozialer Impact“, also eine positive Wirkung für das Gemeinwohl, entstehen kann.

Wichtig ist, dass der Neuigkeitswert der Projektidee und auch das längerfristige Potenzial der Innovation gut erkennbar sind.

Bedarf fundiert begründen und nach Möglichkeit belegen.

In jedem Fall sollte deutlich werden, dass Ihre Innovation hohen Neuigkeitswert besitzt und auf eine konkrete Problemstellung, einen Nutzen für die Zielgruppe (bei uns die Gesellschaft ?), einen unbefriedigten Bedarf o. Ä. zielt. In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftliche Nachhaltigkeit und sozialer Impact bewertet.

[aus meinem Text - habe ich als Kurztetxt genommen] Teilen und somit nachhaltige Ressourcenschonung im Alltag zu stärken und zu etablieren ist die adressierte Herausforderung: Alle haben unzählige Güter, die nur zeitweise genutzt werden. Eine Bohrmaschine z.B. wird im Schnitt pro Jahr nur eine Stunde genutzt und liegt ansonsten im Schrank. Eigentlich könnten diese Dinge auch Freunden oder Nachbarn, d.h. Anderen zur Verfügung gestellt werden. Und nicht nur private Ressourcen, sondern auch die von Organisationen und Institutionen, Unternehmen oder Einrichtungen der kommunalen Daseinsvorsorge werden nicht so genutzt, wie sie könnten. Überlassung ist an Kriterien und Bedingungen geknüpft. Beispielsweise muss die Fähigkeit zur sachkundigen Handhabung eines Dings, die Zugehörigkeit zu einer autorisierten Personengruppe oder bestehender Versicherungsschutz nachgewiesen werden, damit Zugang gewährt werden kann. [bis hier als Kurztext genutzt]

Gesamtgesellschaftlich wird Zugang zu den Ressourcen, die wir teilen und damit temporär besitzen können, benötigt.

Ressourcen gemeinsam nutzen ! *Open Source, Gemeingüter, Teilhabe, Ressourcenschonung, Sharing "Nutzen ist das neue Haben“ und „Teilen ist das neue Besitzen“. Zugang zu.. statt Eigentum an… Mit dem Projekt Fab:Access startet ein quelloffenes, multifunktionales und plattformunabhängiges Open Source Soft- und Hardware Zugangssystem. Dies gilt es im Praxistest zu prüfen, zu optimieren und abschliessend zu etablieren. Eine förderierbare Automatisierungslösung für partizipative Strukturen und Communities. Sie soll den Teilnehmenden eine selbstgesteuerte, sichere und gleichberechtigte Nutzung von Ressourcen garantieren, durch eine leichte Berechtigungs- und Nutzenden-Verwaltung.

2. Lösungsansatz -

in zwei Teile gegliedert: Zum einen den Kern Ihrer Projektidee überzeugend beschreiben [2.1]: WIE wollen Sie den identifizierten Bedarf decken, WELCHE Lösung im Bereich Bildung/Informationszugang wollen Sie der adressierten Gruppe bzw. den potentiellen Kunden anbieten? Zum anderen müssen Sie die geplante Umsetzung [2.2] ausführlich darstellen. Erläutern Sie dafür nachvollziehbar, wie Sie (ggf. gemeinsam mit Kooperationspartnern) Ihre Projektidee realisieren wollen. Zudem haben Sie an dieser Stelle die Gelegenheit, Ihrer Teilnahmeskizze zwei Abbildungen beizufügen. Wählen Sie Abbildungen, durch die Ihr Lösungsansatz gut für Dritte nachvollziehbar wird. Nutzen Sie die Abbildungen, um Inhalte zu transportieren! In dieser Kategorie werden vor allem die Bewertungskriterien Qualität und Überzeugungskraft des Projekts bewertet.

2.1 Geschäftsidee/Pionierlösung

Die Darstellung Ihrer Geschäftsidee/Pionierlösung muss ohne weitere Quellen/Verweise/Dokumente verständlich und überzeugend sein. Quellenangaben und externe Verlinkungen können als Belege für Ihre Aussagen genannt werden, sie dürfen aber nicht für das Verständnis der Skizze essentiell sein! Beschreiben Sie,wie Ihre Geschäftsidee/Pionierlösung den Innovationsbedarf adressiert und ggf. die identifizierte Angebotslücke ausnutzt. Dabei ist es wichtig, die Idee mit ihren Stärken,Potentialen und vor allem ihrem Neuigkeitswert prägnant darzustellen. Beschreiben Sie bitte, welchen Mehrwert die von Ihnen adressierte Zielgruppe durch Ihre Pionierlösung gewinntund arbeiten Sie u.a.damit das Alleinstellungsmerkmal Ihrer Innovation heraus. Gehen Sie bitte auch auf die grundsätzliche Machbarkeit ein, und vermitteln Sie diese insbesondere für Projekte der Projektform B, z. B.durch den Verweis auf geleistete Vorarbeiten.

[aus meinem Text] In Offenen Werkstätten werden Räume, Werkzeuge und Maschinen, Materialien und Wissen bereits selbstverständlich geteilt, gemeinsam genutzt und gepflegt. Eine der wesentlichen Herausforderungen dieser offenen Communities ist, den Zugriff auf Infrastrukturen (Maschinen, Räume, Objekte) so auszubalancieren, dass jedes Individuum sich gleichberechtigt und niederschwellig maximal entfalten kann und gleichzeitig die „Tragik der Allmende“, d.h. die Einschränkung der Möglichkeiten Dritter durch Übernutzung oder rücksichtsloses Verhalten, möglichst minimal bleibt. Diese Praxis und Herausforderung gilt es, gesamtgesellschaftlich zu etablieren. In Nachbarschaften, in und zwischen Unternehmen, in Einrichtungen der öffentlichen Daseinsvorsorge, etc. Ausgehend von denen, die diese Praxis bereits leben hin zu jenen, für die es bisher fremd ist Damit Sharing auf gesellschaftliche Resonanz jenseits von Vermiet-Geschäftsideen stoßen kann, sind digitale Werkzeuge wichtig, die den Gemeinwohlinteressen und der Entwicklung von Nachhaltigkeitskulturen verpflichtet sind und Kooperation statt Konkurrenz, Zugang statt Ausschluss sowie Gemeinwohl statt Egoismus fördern.

Beispiele für Finanzierung:

[name=T. Mulzer] s/Cases/Fällen/ ?

  1. Lösungsansatz -

2.2 Umsetzung (max. 3.500 Zeichen)

Hier müssen Sie den geplanten Lösungsweg zur Realisierung Ihrer Projektidee darlegen. Dazu gehört eine Erläuterung von aufeinander aufbauenden Projektphasen im beantragten Projekt mit nachvollziehbarer Beschreibung von Arbeitsinhalten, eine Darstellung des Entwicklungs-bzw. Anpassungsbedarfs sowie Beschreibungen von Herausforderungen und Risiken entlang des Lösungsweges, die auch den Förderbedarf (d. h. keine Finanzierung aus eigenen Mitteln möglich) belegen. Definieren Sie möglichst auch Meilensteine für Ihr Projekt. Diese stellen wichtige Etappen entlang des Lösungsweges dar, also Teilziele, an denen Sie den Projektfortschritt messen können. Falls Sie ein Kooperationsprojekt beantragen, sollte deutlich werden, welcher Partner welchen Anteil leistet und welche Meilensteine für welches Teilvorhaben relevant sind. Die Meilensteine sollten Ihnen zeigen, ob Sie mit dem ursprünglich angestrebten Lösungsweg Ihre Ziele erreichen können. Erläutern Sie hier, ob Sie das Projekt nur mit Ihrem Team bzw. den Projektpartnern umsetzen können, oder ob Sie Zuarbeiten von Dritten benötigen, wofür die Vergabe von Aufträgen ? erforderlich wäre. Diese Aufträge an Dritte sollten an dieser Stelle kurz erläutert werden. Wer soll welche Aufgaben wann für das Projektumsetzen? Wie werden diese Ergebnisse im Projekt verwendet?

Was liefert das aktuelle Projekt bis Juni 2021 ?/ Wo steigen wir im Juli 2021 ein ?

Minimum viable Product entwickeln und dann in der Community testen Testbetrieb mit den ausgewählten, beteiligten Orten/ Projekten für 6 Monate plus 1 Monat Vor- sowie 1 Monat Nachbereitung

Orte mit verschiedenen Anforderungen, z.B. im ländlichen oder urbanen Raum, mehr-Gewerke-Projekte wie Konglomerat eV in Dresden oder Eigenbaukombinat in Halle, andere Gemeinschaftseinrichtungen wie zB. Stadtteiltreffs, Gemeinschaftsgärten oder ...?

Bisher haben wir recht homogene Orte, keine Bibliothek oder was weiss ich. Vielleicht starten wir mit unseren Orten und nehem im letzten Drittel noch 1-2 andere Orte mit anderen Voraussetzungen dazu ?so 1/3 der Zeit mit unseren Orten arbeiten, im 2/3 2 weitere Orte mit weiteren Herausforderungen ausfindig machen und die im letzten Drittel dann mit reinholen ?

[name=T. Mulzer] Vorschlag aus der TH Brandenburg: Klimawerkstatt, Werder/Havel [name=J. Bijkerk] macht Sinn

Entwurf Anschreibe-Text für die bisher anvisierten Orte: Hallo Ihr Menschen vom xy, aktuell ist das Zugangstool Open:Acces (https://fab-access.org/de/projects/fabaccess/) in Entwicklung. Damit es gut in die Landschaft der Offenen Werkstätten, Makerspaces, etc. eingeführt werden kann, wollen wir einen Testphase organisieren, in der wir mit Orten, welche verschiedene Anforderungen mitbringen, zusammen arbeiten in der Erprobung und Praxisanwendung des Tools. Gerne möchten wir auch euch dazu einladen. Was braucht es dazu ? Ein bis zwei verbindliche Ansprechpartner, die zusammen mit uns Entwicklern und Menschen vom Verbund der Offenen Werkstätten 6 Monate das Tool testen. Los gehen soll es, so die Ressourcen bis dahin akquiriert sind, im August 2021 bis einschliesslich Januar 2022. In eurem Space soll Open:Access angewendet werden und ihr berichtet uns und den anderen Orten die ebenalls in dieser Phase dabei sind, was wie läuft, fehlt, verändert werden sollte usw. Ihr arbeitet also bei euch vor Ort und nehmt an Austauschrunden mit uns und allen in diesen 6 Monaten teil. Bitte gebt uns bescheid, ob ihr dabei seid und wenn ja, wer von euch für uns die Kontaktperson(en) sind. ... ==> gerne ergänzen, umschreiben etc ! - Danke

Weitere Anwendungen des Tools in diesen Netzwerken/ Verbünden:

Ein (Software)Projekt, das soziale Strukturen unterstützt und entwickelt und nicht eins, das primär kommerzielle Interessen bedient. Was auch durch und mit diesen Strukturen sich weiter entwickelt, Beispiel freifunk.net

Durch das Tool bekommen viele Menschen die Möglichkeit, sichere/ überschaubare Zugänge zu Infrastruktur zu erhalten ohne das dazu immer eine Zugang-gebende Person vor Ort sein muss.

Skalierbar und damit von grossem Interesse für das Gemeinwohl.

3. Wettbewerb (max.3.000 Zeichen)

Hier soll erläutert werden, wie sich Ihre angestrebte Lösung vom Wettbewerb im Sinne bereits bestehender vergleichbarer Angebote abhebt, sowohl national als auch international. Nutzen Sie die Kategorie, um den Gutachterinnen und Gutachtern zu zeigen, dass Sie das spezifische (Wettbewerbs-)Umfeld kennen und um möglichenationale und internationale Anbieter und deren alternative Lösungen/Angebote wissen. Wie viele und welche direkten Konkurrenten bzw. andere Anbieter gibt es ggf.und wo sehen Sie Vor- bzw. auch Nachteile Ihrer angestrebten Innovation? Welche Markteintrittsbarrieren oder Herausforderungen bei der Implementierung bestehen? Dies betrifft u. U. auch regulative Rahmenbedingungen sowie Patent-und Schutzrechte. Nur wenn Sie das spezifische Anbieterumfeld bzw. den bestehenden Wettbewerb klar und präzise beschreiben, wird auch der Wettbewerbsvorteil Ihres Ansatzes bzw. sein Alleinstellungsmerkmal nachvollziehbar! Dadurch können Sie auch verdeutlichen, welche ungenutzten Potenziale u.a. in Hinblick auf gesellschaftlichen Nutzen durch Ihre Innovation gehoben werden können. Benennen Sie zudem ganz konkret, worin bzw. wie sich Ihre Innovation von bestehenden Lösungen unterscheidet. Belegen Sie dies mit konkreten (soweit möglich auch quantitativen) Parametern/Aspekten Ihrer Innovation im Vergleich zu verfügbaren Lösungen. Bei Projekten der Form A, die sich noch in der innovativen Frühphase befinden, kann eine detaillierte Wettbewerbsanalyse dagegen Teil des vorgesehenen Machbarkeitstests sein. Gleichwohl muss auch in diesem Fall grundlegendend beschrieben werden, wie sich die angestrebte Innovation von Bestehendem abheben soll. Bitte verweisen Sie zudem möglichst mit Links auf bestehende Konkurrenzlösungen, von denen Sie sich abheben möchten (Beispiel https://fabman.io/ - was gibt es noch ?). In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftlicheNachhaltigkeit und sozialer Impact bewertet!

""einer durchgeführten Recherche zu Vor- und Nachteilen eingesetzter Zugangssysteme wo finde ich das ???

Es existieren bereits technische Lösungen für Zugangssysteme (Fabman.io), allerdings sind diese proprietär und von teuren Lizenzen abhängig und oft an sehr spezifische Anwendungsbereiche angepasst, die der Vielfalt offener Räume und ihrer Bedürfnisse nicht gerecht werden. bestehende Systeme sind … zu teuer Fabman.io - Anschaffung: ca. 4.700€ (bei 20 Geräte), laufende Kosten 350€/ Monat FabAccess - Anschaffung: ca. 1.000€ (bei 20 Geräte), keine laufende Kosten. … passen nicht vollständig zu unseren Bedürfnissen. … nicht problemlos in bestehende Strukturen integrierbar … kein föderativen Ansatz … nicht für andere soziale Konzepte verwendbar ... nicht selber veränderbar Fab:Access

Was sind dabei unsere Ziele?
    Das System soll sich verbreiten, das bedeutet.
        Das System soll auf einer möglichst breiten und agilen Basis entwickelt werden.
        Wir wollen für die User entwickeln, nicht für uns.
        Das System soll Menschen Arbeit abnehmen statt aufbürden.
    Das System soll im Rahmen einer nachhaltigen Struktur entstehen - nicht an einer Person hängen, sondern jederzeit durch andere weiterentwickelt werden können.
    –> strictly OpenSource.
    In Zukunft optional als Föderation funktionieren

Leihs ist ein Ausleihsystem das an der ZHDK (Züricher Hochschule der Künste) entwickelt wird. Es bietet Datenstrukturen die ausleihbare Gegenstände gut beschreiben. FabAccess wird Schnittstellen zu Leihs haben.

FabManager ist ein Managementsystem für offene Werkstätten als Open Source Lösung. Das System ist ein "Copy-Paste system" mit dem für offene Werkstätten ein Mitglieds- und Maschinenmanagement System zur Verfügung steht. Die Anbindung von FabAccess an Fabmanager würde für offene Werkstätten ein vollwertiges Verwaltungssystem als Open Source Lösung darstellen. FabManager wurde in Frankreich entwickelt. besteht Kontakt ? können wir den benennen ?

Sammlung laufender Aktivitäten: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ?both

Referenztexte (Beispielhaft) https://tools.ietf.org/html/rfc7831 Application Bridging for Federated Access Beyond Web (ABFAB) von 05/2016 by Internet Engineering Task Force (IETF) Architecture/ Bedeutung von Förderation

https://medium.com/mozilla-open-innovation research report from Mozilla and Open Tech Strategies provides new perspectives on framing open source strategy. 05/2018

4.1 Antragstellende Unternehmen und Einrichtungen (max 2000 Zeichen)

Eignung, Erfahrungen und Kompetenzen des Skizzeneinreichersbzw. der einreichenden Unternehmen/ Einrichtungen, Vorarbeiten und Referenzen eingehen, so dass die Eignung deutlich wird. Bei Kooperationsprojekten soll hier zudem deutlich werden, in welcher Form sich die antragstellenden Unternehmen/Einrichtungen komplementär als Projektpartner ergänzen und wie die Zusammenarbeit bzw. Arbeitsteilung zwischen den Partnern und den wesentlichen mitarbeitenden Personen gestaltet werden soll. Geben Sie bitte eine kurze Kompetenzbeschreibung eines jeden Kooperationspartners ab.

Verbund Offener Werkstätten e.V. zusammen mit?

4.2 Qualifikation der vorgesehenen Mitarbeiter

stellen Sie die am Projekt voraussichtlich mitwirkenden Personen bzgl. Berufs-, Bildungs-und Erfahrungshintergründen vor, inklusive Schlüsselqualifikationen und relevante Arbeitserfahrungen, so dass die Eignung der vorgesehenen Personen beurteilt werden kann Frauke Hehl VOW /Koordination Maximilian Voigt (begleitend ?) VOW /Koordination Tasso Mulzer Joris Bijkerk (Tester und Beschaffung und Bau von Hardware) Gregor, Kai, Joseph, ... weitere Entwickler ?

https://www.heise.de/news/FabAccess-Bessere-Maschinenverwaltung-fuer-Fablabs-5027184.html?fbclid=IwAR0dbaOY20l3n2RuR8D8RbOV9Y_KmausQqqMsZSe7qP4oxqYE5o64La-1IE

5. Wirkungspotenzial (max. 3.000 Zeichen)

Bitte erläutern Sie, welches Potential Ihre Innovationhat, von der adressierten Zielgruppe angenommen zu werden und auf diese Weise eine nachhaltige positive Wirkung für das Gemeinwohl zu entfalten. Idealerweise sollte ein möglicher gesellschaftlicher Nutzen deutlich werden, der deutlich über das Projekt hinausgeht. Schätzen Sie dabei bitte die Anzahl der möglichen Nutzer samt der Nutzungsintensität bzw. die Marktgröße ab. Bitte achten Sie darauf, dass der gesellschaftliche Nutzen Ihrer Innovation möglichst objektiv dargestellt werden sollte, so,dass z.B. ein breiter gesellschaftlicher Konsens über den Nutzen nachvollziehbar ist. Von großer Bedeutung ist zudem die „wirtschaftliche Nachhaltigkeit“ Ihres Projekts. Bitte stellen Sie dar, wie die zu entwickelnde Pionierlösung bzw. das zu entwickelnde Geschäftsmodell („Projektergebnis“) prosperieren soll bzw. auch nach der IGP-Förderungwirtschaftlich tragfähig ist und aus eigener Kraft weiterexistieren bzw. -expandieren kann. Dies wird in der Regel gut durch die Darstellung eines entsprechenden Umsatzpotenzials möglich sein. Sollte die Natur Ihrer Lösung derart sein, dass sie selbst keinen Umsatz generieren kann, sollte ein Konzept vorgelegt werden, wie das Fortbestehen der Lösung insbesondere durch andere Finanzierungsquellen (z.B. Sponsoring, Spenden, Lizensierung) nach Auslaufen der IGP-Förderung gut gesichert werden kann. Es sollte ersichtlich werden, dass das Projektansinnen mindestens verstetigt werden kann, auch wenn die Förderung durch IGP beendet ist. Wünschenswert wäre eine über die Verstetigung hinausgehende Prosperität des Projektergebnisses nach Förderende. Die Schwerpunkte Ihrer Ausführungen in dieser Kategorie sollten je nach Projektform wie folgt ausgelegt werden:Projektform A: Ordnen Sie bitte das Thema Ihres Machbarkeitstests im zu untersuchenden Umfeld/Markt ein. Es sollte u.a. deutlich werden, ob Sie eine Lösung für eine Nische schaffen wollen und wenn ja, wie groß diese Nische ist oder ob Sie sich im Wettbewerb mit sehr vielen anderen Teilnehmern befinden. Welche Ideen haben Sie bereits,potentielle Nutzer zu überzeugen bzw. Anteile dieses Marktes zu erobern? In der Kategorie „Wirkungspotenzial“ werden vor allem die Bewertungskriterien sozialer Impact und wirtschaftliche Nachhaltigkeit bewertet.

[aus meinem Text] Zukunftsfähige Werteorientierungen leiten das Handeln und fördern Gerechtigkeit im Miteinander.

Open Source Code und Hardware, umfassend dokumentiert und als gemeines Gut kostenfrei für alle veröffentlicht und nutzbar gestaltet. Ohne spezifische technische Vorkenntnisse vorauszusetzen. Aufbauend auf einer durchgeführten Recherche zu Vor- und Nachteilen eingesetzter Zugangssysteme, ist ein entsprechendes OS-System in unserem Netzwerk bereits in Programmierung. Akteure u.a. von der Beuth Hochschule für Technik Berlin und der Eidgenössischen Technischen Hochschule Zürich arbeiten daran. Um die Idee weiter entwickeln zu können, muss der Umsetzungsplan vom status quo zum „minimum viable system“ konzipiert werden. Das Netzwerk würde mithilfe des Preisgeldes um Mitwirkende aus weiteren Einrichtungen aus Wissenschaft, Forschung und Entwicklung erweitert. Neben fachlicher Expertise sind Kompetenz zur internen, wie externen Kommunikation und Öffentlichkeitsarbeit hilfreich, sowie zielgerichtetes Vorgehen bei Implementierung und den iterativen Weiterentwicklungsphasen mit der Werkstätten-Community.

Im Produktiveinsatz in ausgewählten Offenen Werkstätten können neben soft- und hardware-Aspekten insbesondere die leitenden Arbeitshypothesen überprüft werden (zu Auswirkungen auf Diversität, Teilhabe und Engagement von Nutzer*innen, sowie Management und Organisationsentwicklung beispielsweise). Ein evaluierter Proof of Concept erleichtert dann die Übertragung der Soft- und Hardware auf andere Kontexte, für die Zugangs- und Berechtigungsregelungen etabliert werden. Ziel ist, transdisziplinäre Anwendungs- und Forschungssettings zu entwickeln, d.h. die Idee in verschiedenen Reallaboren zu testen. Beispielsweise in Bibliotheken, Unternehmen, Bildungseinrichtungen, etc.

Die direkte Folge einer Umsetzung der Idee Fab:Access kann sein, dass die bisherige Landschaft der infrastrukturteilenden Communities wie die der Offenen Werkstätten einen starken Wachstumsschub erleben und sich weiter diversifizieren. Auf der Plattform www.offene-werkstaetten.org sind derzeit ca. 400 Initiativen unterschiedlichster Art und Größe verzeichnet. Je einfacher und aufwandsärmer es wird gemeinschaftliche Güter und Infrastrukturen zu managen, desto wahrscheinlicher, dass andere von dieser sozialen Innovation angesteckt werden und diese sich verbreitet. Im urbanen wie im ländlichen Raum. Durch das System können beliebige Infrastrukturen geöffnet und zugänglich gemacht werden, d.h. brachliegende Ressourcen könnten zur „Offenen Werkstatt“ werden. Bürger*innen könnten über ein einfaches und individualisierbares, kostenfreies System für Sharing diese Kultur des Teilens in gelebte Alltagspraxis überführen und Ressourcen mit anderen gemeinsam drüber nutzen.

Plattformübergreifend heißt u.a. auch möglichst große Flexibilität bei der Systemwahl. Ob nun Desktop- oder Serverlösung, App oder RFID-Karten… Langfristig könnten multiple Lösungen entstehen, die es erlauben sicher und DSGVO-konform individuelle und gruppenbezogene Zugangsberechtigungen, sowie solche mit z.B. örtlich-geografischer Reichweite, zu verwalten: Ein förderiertes IT-System für Sharing. Statt eines Vertriebssystems für ein technisches Produkt, wird es über lokale Offene Werkstätten reale Anlaufpunkte geben, in denen diese digitalen Werkzeuge und Hilfsmittel für Sharing adaptiert und eingesetzt werden. Hilfe für die Anwendung in anderem Kontext kann hier eingeholt werden, wie heute schon Offene Werkstätten Knotenpunkte lokaler Nachbarschaftshilfe darstellen. Commoning statt Business, d.h. ein Ökosystem hilft die (neue) Kultur und Praxis des Teilens in die Kapillaren der Gesellschaft vordringen zu lassen.

6. Förderbedarf (max. 2.000 Zeichen)

Erläutern, warum staatlicher Förderbedarf ? Dabei sollten Sie auf die Risiken und Herausforderungen eingehen, die Sie bei der Umsetzung der Projektidee erwarten (siehe Abschnitt 2.2) und die eine private oder anderweitige Finanzierung des Projekts ggf. erschweren. Warum das Projekt nicht vollständig aus Eigenmitteln bezahlt werden kann ? Nur Förderung, wenn es ohne Förderung gar nicht oder nur mit Zeitverzögerung und in bedeutend geringerem Umfang realisiert werden könnte ! In dieser Kategorie werden vor allem die Bewertungskriterien Anreizeffekt und Innovationswagnis bewertet.

Finanzierung 75% (bei Gemeinnützigkeit) Zuwendung, Rest Eigen- oder Drittmittel, maximale Zuwendung 49.000€ Eigenmittel könnte aktuell der VOW beisteuern (bis zu 20.000€) BEACHTE DIE VORGABEN ZUR HONORARGESTALTUNG !

[name=J. Bijkerk] Hardware-Kosten: Je "Ort" brauchen wir

Bewertungskriterien

zu den einzelnen Tops die wir beantworten müssen, wird am Ende immer genannt, welches Bewertungskriterium dafür besonders relevant ist.

Antragsdokumente

Telegram-Gruppe

26.01.2021 // Borepin Doc

Known Bugs

https://github.com/xamarin/Xamarin.Forms/issues/1575
https://github.com/xamarin/Xamarin.Forms/issues/10437

 

22.01.2021 // Antwort Repair-Cafe

Sehr geehrte Damen und Herren,

eignet sich Ihre neue Plattform auch für Repair-Cafes? Ich suche schon lange so ein Ticketsystem, damit ich z.B. nicht mit meinem kaputten Breitbild-Fernseher mit Bus & Bahn zum nächsten Repair-Cafe fahre um dann zu erfahren, dass keiner Zeit für mein Problem hat oder sich nicht auskennt und ich unverrichteter Dinge wieder nach Hause fahren muß. Die Dingfabrik in Köln ist sowieso der Meinung, dass so ein Cafe als Schwerpunkt "Cafe und Kuchen" hat, weil es ja alles Freiwillige sind, die das machen? Wenn die freiwillige Feuerwehr auch diesen Standpunkt vertreten würde, dann würde Ihr brenndes Haus nicht mehr gelöscht, oder wenn andere Dienste wie z.B. das DRK, dass auch vorrangig von Freiwilligen organisiert wird, so denken würde, dann würden keine Blutspendetermine mehr laufen um Leben zu retten, oder die Corona-Impfungen könnten nicht stattfinden, weil die Ehrenamtlichen gerade Kaffee trinken und Kuchen essen Aber die Betonköpfe von der Dingfabrik lassen sich leider nicht umstimmen und lehnen mein Engagement ab. Daher versuche ich schon länger etwas Alternatives auf die Beine zu stellen durch ein Repair-Wiki oder eine Plattform, wo man seine Dienste bereitstellen kann und Leute darauf reagieren können. Aber da ich nur eine Privatperson bin, weiß ich zur Zeit nicht wie ich es zeitlich, räumlich und personell organisieren soll? Sind Sie auch der Meinung, dass man weiter der Umwelt schaden sollte und massiv Elektroschrott produzieren soll, weil es kein Recht auf Reparatur gibt? Oder würden Sie auch für den Umweltschutz eintreten und mir helfen meine Idee in die Tat umzusetzen? Leider kenne ich mich mit "Cap'n Proto" nicht aus. Warum schreiben Sie es nicht mit PHP oder Python, dann könnte ich Sie unterstützen. Über eine freundliche und konstruktive Antwort würde ich mich sehr freuen.

Mit freundlichen Grüßen

Meinungen:

Kurzantworten: eignet sich Ihre neue Plattform auch für Repair-Cafes? Prinzipiell ja, sofern RepairCafes Maschinen zur Nutzung anbieten und Einweisungen dafür geben. Allerdings eher nicht, für dass was Sie vorhaben ... wir werden aber nicht in das Termin-Management von Repair-Cafes eingreifen und das wird FabAccess auch nicht darstellen.

Ticketsystem Für ein Ticket System gibt es bessere Alternativen, Jira oder RequestTracker zum Beispiel.

Sind Sie auch der Meinung, dass man weiter der Umwelt schaden sollte und massiv Elektroschrott produzieren soll, weil es kein Recht auf Reparatur gibt? Nein

Oder würden Sie auch für den Umweltschutz eintreten und mir helfen meine Idee in die Tat umzusetzen? Können wir leider nicht (... wir sind mit FabAccess ausreichend beschäftigt... und nicht in Köln.)

Warum schreiben Sie es nicht mit PHP oder Python, dann könnte ich Sie unterstützen. 0. Weil ich will. * PHP / Python ist nicht besser als $Language, auch nicht als Rust. * Rust ist nicht besser als $Language, auch nicht als PHP. * Aber ich schreibe die software nunmal anstatt mich drueber auszuhaeulen wie schlimm $Repaircafe ist. Also ist es Rust.

  1. Warum nicht PHP/Python sondern spezifisch Rust?

    • Geschwindigkeit
      • Und damit Effizienz. Die Tatsache das wir Python verwenden traegt inzwischen nicht unwesentlich zum Klimawandel bei.
    • Sicherheit
      • Gegen Bugs die in Netzwerksoftware oft Exploits verursachen, z.b. double free, buffer overflow (vgl. Heartbleed), buffer underflow aber auch gegen Logik-Bugs durch starke Typen
    • Stabilität
      • Sowohl auf ABI-level, Rust hängt am Ende nur noch von der glibc ab
      • Die Software selber wird dadurch weniger warscheinlich abstürzen
    • Ich kann Rust besser als Python und wesentlich besser als PHP

  2. Cap'n Proto ist keine Programmiersprache sondern eine Schemasprache und definiert die Schnittstelle sinnvoll damit externe [Personen] Clients sinnvoll schreiben können und die nicht ständig in die Luft fliegen weil irgendwas irgendwo eine Sache im Api ändert die inkompatibel ist

  3. Es wird eine Python Implentation der API geben, mit der kann dann ein eigener Client geschrieben werden

Antwort

Sehr geehrter Herr M....,

unsere Software FabAccess ist zur Verwaltung von FabLabs und offenen Werkstätten gedacht, um so den Umgang mit Maschinen sicherer zu machen. Für den Einsatz in Repair-Cafes eignet sich unsere Software nur, wenn in diesem Umfeld Maschinen oder Gegenstände verliehen werden.

Für das Vorhaben was Sie anstreben bietet sich aus unserer Sicht eher ein Open Source Ticket System wie Jira oder RequestTracker an. Teilweise wird so etwas auch z.B. auf Discourse abgebildet. Auf einer solchen Plattform könnte Ihre Idee aufgebaut werden.

Wir unterstützten natürlich den Ansatz von Repair-Cafes, mehr zu reparieren und weniger zu entsorgen. Manche von uns sind auch in RepairCafes direkt aktiv und beteiligt. Allerding kann unsere Software bei diesem Problem nicht helfen.

Leider können wir Ihnen bei Ihrem Projekt nicht helfen, aber wir hoffen wir konnten Ihnen einen Weg zeigen, wie Sie mit Ihrem Projekt starten können.

Die Toolwahl wurde tatsächlich am Projekt-Start ausführlich disktuiert und ist für unser Projekt den Kenntnissen unserer Entwickler gefolgt, um in der kurzen Zeit der Föderphase einen langfristig schnell und stabil laufenden und möglichst von Programmierfehlern freien Prototypen zu erhalten. Der Rust-Compiler verhindert an der Stelle Fehler, die in anderen Programmiersprachen gerne übersehen werden und produziert dabei sehr effizienten Maschinencode ohne viele externe Abhängigkeiten.

Als Info für Sie: Bei Capt'n Proto handelt es sich nicht um eine Programiersprache die wir verwenden, sondern um die Schemasprache mit der wir unsere API definieren. Für unseren Anwendungszweck, eine möglichst stabile und erweiterbare API zu bauen eignet sich Capt'n Proto daher besonders gut. Über diese Herangehensweise können wir anderen Open Source Entwicklern wie Ihnen eine Möglichkeit geben unsere Software zu erweitern, wie zu Beispiel einen eigenen Client zu schreiben.

Wir hoffen wir konnten Ihre Fragen alle beantworten und wünschen Ihnen noch viel Glück und Erfolg bei der Umsetzung Ihrer Idee, die Repair-Cafes zu revolutionieren.

Mit freundlichen Grüßen

Das Fab-Infra Team

21.01.2021 // API Meeting

Bootstrap Interface, für Informationen ohne Authentifizierung Von dort aus kann man sich dann Authentifizieren

Bootstrap Interface:

Maschine Subsystem:

Permission Subsystem (Admin):

Interaction Subsystem:

Föderation Subsystem:

Authorisierung passiert auf Interface Level.

Über das Bootstrap Interface können mehrer Verbindungen aufgemacht werden.

Föderated Sachen sind immer authentifiziert über ein Zertifikat.

Audit Log

15.01.2021 // Maschinenlist - D,A,CH

Maschinenlist - D,A,CH

Hier können die verschienden genutzten Maschine je FabLab eingetragen werden.

Den FabLab Namen bitte als Überschrift einfügen.

BHT

FVM-Labor / FabLab

Art Hersteller Typ/Bezeichnung Anschluss Besonderheiten
Werkzeugfräse Mikron WF31DE 16A, 3phasig eine Phase reicht. Evtl. spannend, die Maschine mit Überwachung/Steuerung einer Absauganlage / Kühlmittelpumpe zu ergänzen.
Drehbank Leinen MLZ 16A, 3phasig eine Phase reicht.
Wasserstrahl Flow Systems FlowJet 64A?, 3phasig eine Phase reicht. Evtl. Kühlwassersteuerung automatisieren.
Senkerodieranlage Mitsubishi J80 32A, 3phasig eine Phase reicht.
Dampfphasen-Lötanlage IBL --- 16A, 3phasig Vorlaufzeit ca. 30 min. Nachlaufzeit einige Stunden. Sollte mit dem Kühlaggregat gekoppelt werden (Kühlung springt mit Maschine an, Maschine lässt sich nicht ohne Kühlung betreiben). Wassersteuerung integrieren.
Multilayer-Presse HML --- 16A, 3phasig Sollte mit dem Kühlaggregat gekoppelt werden.
Präzisionsbohrfräse Klingelnberg Alpha 01l 16A, 3phasig Sollte mit dem Kühlaggregat gekoppelt werden.
Bestückautomat Mydata TP9 SchuKo
Bestückautomat ATN InoPlacer SchuKo
Leiterplattenfräse LPKF ProtoMat S62 SchuKo
Metallsäge ... ... SchuKo Sichern
Bohrmaschine Maxion Unimax 1 Frequenz SchuKo Sichern
Bohrmaschine Flott --- SchuKo Sichern
Galvanik-Anlage Bungard --- SchuKo Sichern
Galvanik-Anlage Englert --- 16A, 3phasig Sichern
Werkzeugwagen Perschmann --- nur Ausleihe Evtl. Bild-Station / Waage / ... für Rückgabe bauen.
Löt-Tische Weller / JBL / ... verschieden Tisch-Stromleiste verhindern, dass einfach am Nachbar-Tisch angeklemmt wird?

09.12.2020 // Punkte Chaostreff Potsdam

wir müssen man bei den Schweizern nachfragen, wie es bei denen steht

modify permissions on the fly

Meldesystem für defekte Maschinen

PiImage für FabAccess

An Konferenz im Oktober teilnehmen

06.12.2020 // Transcript Test Meeting

Tasso (Laborleiter) aus dem Labor in der Uni soll ein FabLab werden.

Schöne Geschichte: 2016 wollte Tasso eine FabLab bauen, Idee durch Makerfaire

Was ist ein FabLab? Ein Fabrication Laboratorie, nach der Idee von Nile Gerschenfield vom MIT (2005), Studenten soll die Maschine bedinenen können, um so Mitarbeiter für das Forschungsprojekt zu haben. How to make allmost anything, war der Name des Kurses Durch diesen Kurs trafen sich verschiendenste Studenten, die nicht geahnte Projekte umsetzten.

2007 Konzept für FabLab erstellt.

Wir wollen an der Beuth studierende nach diesem Konzept ausbilden.

In Tassos Labor steht eine Drehbank, nach der Idee von Niel Gerschenfiled sollen Studierende autoditaktisch den Umgang mit dieser Machiene lernen. Das ist ein anderer Ansatz als früher mit 3 Jahre Ausbildung, dabei hat man den Umgang mit der Maschine unter Aufsicht erlernt. Tasso mangelt es an 5 Werkstattmeistern, die darauf achten, dass sich die Studierende nicht weh tun. Bei 25 bis 28 Studenten im Labor und dann nicht alle in einem Raum, dadurch kann nicht gesteuert werden, wer die Drehbank ein und ausschaltet. Dadruch wurde ein Schütz an die Drehbank geklemmt, mit einem ESP8266. Um die Maschine mit WLAN ein und aus zuschalten. Mit MQTT und OpenHAB. OpenHAB ist eine Smart Home software, die mit Logik aktoren und Sensoren verbindet. Der Nachteil von OpenHAB ist, dass jeder der im gleichen Netzwerk wie die Drehbank ist, kann jede Maschine ein und ausschalten. Eine Drehbank aus der Ferne ein und auszuschalten ist gefährlich. Die Drehbank ist eine gefährliche Maschine, wenn man nicht eingewiesen ist, wird aber in einem FabLab benötigt.

2018 und 2019 gab es Leute mit FabLabs die sich in der Uni Siegen getroffen haben. Tasso fragt in die Runde ob wer das selbe Problem hat und ob jemand an einer Steuerungssoftware arbeitet. Darauf haben sich 2 (von 25) Leute gemeldet, die daran arbeiten, mit einem Prototyp. Nach weiteren Rückfragen stellte sich raus Work for Me. 2019 die gleiche Frage 8 Leute melden sich von 80 Leuten, auf die Frage wer das veröffentlichen möchte, gingen die Hände wieder runter. Tasso hat darauf hin die Vernetzung dieser Gruppen übernommen. 12-13 Projekt, keines Fertig. Klingt einfach ist ja nur Maschine ein und ausschalten, also nur 1 Bit. 2019 der Verband der offenen Werkstätten hat sich als nächstes Projekt gemeldet. Also sollte man eine solche Software nicht nur auf Hochschule beschränken, sondern auch externe FabLabs einbinden. Darauf hin fiel das Stichwort Fereation. Das macht es richtig kopleziert. Novemeber bis Februar wurden viele Calls abgehalten um das alles mal zu sammeln. Gregor wollte das alleine schreiben. Tasso meinte das noch mehr gebruacht werden. Joseph ist dann durch längere Aufenthalte im Labor bei den Meetings dabei gewesen. Kai und Janis haben sich druch die Suche nach Team Mitglidern für den Prototypefunde dazugefunden. Jannis hat zum Go lernen Projekt nummer 15 Eröffnet. Und Gergor hat mir einem QR-Code system Projekt nummer 16 gestartet. Durch den Verband der offenen Werkstätten hat sich der Kontakt und die Idee mit dem Prototypefund ergeben. Daruch wurde Projekt nummer 17 gegründet.

Dadruch wurde einmal alle Anforderungen an das Projekt zusammen getragen, also an das "Core Team" und alles was Tasso noch wusste. "Core Team" (12 Leute) ist ein Teil von 45 Leuten, die sich für das Projekt interessieren und es umsetzten wollten und können. Daraus wurde ein Lastenheft gegossen. Mit einer Anforderungsliste.

RFID Karten - Smartcards Maschine sicher schalten Einfache Machinen abbilden - Es ist egal ob eine Machine ein Drehbank oder ein Schraubenzieher ist, wenn ich die Nutze ist die nicht mehr da. Daruch kann man sehen ob ein Tisch benutzt wird oder nur zumüllt und man den abräumen kann. Maschine als Admin auch nutzten, wenn ein anderer die Maschine gerade "nutzt". Override ist, dass die Maschine auch geht, wenn unser System offline ist. Also wenn BFFH - Diflourboran, also etwas was man nicht bei Google findet. Das ganz soll auf eine Pi laufen können. Unsere Client - Borpin

Zum Konzept Use Cases Die Idee ist, dass du als neuer Nutzer in FabLab kommst und dann die Frage stellst, was muss ich hier tun, damit ich die Maschinen nutzten darf. Aktuell würdest du dir einen Admin suchen, der lässt dich dann einen Vertrag unteschreiben. Also "Leihverträge" ... (nicht so wichtig) Dadurch kannst du jetzt an eine Drehbank gehen und diese einschalten, auch wenn du davon keine Ahnung hast. Dadruch muss der Admin immer genau schauen wer was macht und diese Arbeit soll weg automatisiert werden, damit Tasso mehr Zeit für andere Dinge hat.

Mit unserem System: Als neuer Nutzer kannst du dich über Borpin registrieren und unterschreibst dann einen Vertrag, dann wirst du vom Admin freigeschaltet und bekommst deine SmartCard. Dann darft du erstmal nichts tun, außer unrestricted Maschine nutzten (schraubenzieher) Mit deiner SmartCard kannst du jetzt an eine Maschine gehen und dann wird dir gesagt, dass du nicht nutzten darfst ohne Einweisung. Also musst du zu Tasso gehen und dir eine Einweisung geben lassen. Ab jetzt darfst du die Maschine frei nutzten und Tasso ist aus seiner Sicherungspflicht entbunden. Wir machen dann den Strom ein und aus für diese Maschien, wenn du deine Karte auf den Reader legst.

Abrechnungen ist ein Feature was gefordert wurde, aber wir nicht sofort leisten. Man soll minutengenau deine Maschinen nutzung abrechen.

Studenten chippen ;)

Föderationskonzept Die Zusammenarbeit von Organisationen kann in Form einer Föderation erfolgen, die wie eine politische Föderation organisiert ist: Die Organisationen behalten ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.

Es gibt das Konzept, das man einfach aus zwei Makerspaces eines macht, mit zwei standorten. Das ist nicht so schön.

Durch die Föderation ist es möglich Nutzer zwischen den FabLabs auszutauschen. Das heißt Nutzer die bei Tasso in die Benutzung der Drehbank eingewiesen wurden, da kann Joris in seinem Space der die gleiche Drehbank hat und Tassos Einweisungen vertraut, diesen Nutzer bei sich auch erlauben die Drehbank zu benutzten.

Die Föderation kann auch auf die Abrechnung ausgeweitet werden. Also wenn du als Nutzer von Tasso bei Joris die Drehbank nutzt, dann muss nicht Joris dir dafür eine Rechnung schreiben, sondern dann kommt das durch Tasso. Tasso und Joris müssen dann nur noch die jeweilige Differenz der Beträge überweisen.

Die Föderatoin hat 3 Stufen:

  1. Nutzer können bei anderen Spaces Ihre Karte wiederverwenden. Alos SSO mäßig. Also bei der Einrichung der Föderation ist das der erste Schritt.
  2. Berechtigung können zwischen den Spaces geteilt werden.
  3. Finanzierung, dass kommt erst später

Zu den SmartCard. In normal Fall liegt auf der SmartCard eine verschlüsselte Datei. Wenn du die Datei entschlüsseln kannst, dann ist die Karte Authentifiziert. Also bei MIFARE Classic Karten benötigt der Reader den Schlüssel, um die Datei zu entschlüsseln. Bei DESFire Karten kann die Funktion von OTA genutzt werden. Das heißt, die Kommunikation mit der Karte erfolgt direkt und verschlüsselt zwischen Reader und dem Server selber. Metro Karten nutzten, das zum Beispiel, wenn sie auf der Karte einen Betrag speichern, so kannst du über dein Handy diese Karten aufladen. Dadurch braucht der föderierte Space keine Schlüssel für die Karten des anderen Spaces. Bei DESFire wird ein Session Key generiert, dadurch kann keine Replay Attacke verwendet werden. Durch diese Anforderung haben wir uns für DESFire entschieden. DESFire Karten kosten nur 1€ im Einkauf. SmartCards sind Beständiger gegen Dreck und eignen sich daher besser in FabLabs. Auf den SmartCards sind öffentlich dein Username (kann pseodonimisert werden) und der Space zu dem du gehörst. Also ein DNS Host Adresse.

Nutzertracking Für die Abrechnung wird es benötigt. Aber für den normalen Betrieb wird kein Log benötigt, in dem der Admin sehen kann wer wann welche Maschine benutzt hat. Allerdings wäre es sinnvoll den letzten Nutzer zu speichern, damit man bei Beschädigung den Verursacher ermitteln kann. So kann der neue Nutzer beim Begin der Nutzung feststellen, dass er die Maschine nicht beschädigt hat. Und der Admin dem entsprechend handeln kann.

Unser System soll auch für Schließsystem verwendet werden, die Versicherung lässt grüßen. Daher sollte man schon loggen, wann welcher Nutzer durch diese Tür gegangen ist, um so Diebstähle nachvollziehen zu können.

Maschinen sind generich implementiert, also kann man als Betreiber jeden Aktor verwenden, für den man unsere API implementiert hat.

Wir bauen für das Scannen eine Reader Kit zur Verfügung zum Nachbauen.

Bei Türschlössern geht es uns um den Datenschutz, also wir würden das am liebsten garnicht einbauen.

Leihs ist ein anderes Thema.

Wir haben Sticker im eine Wiedererkennungswert um Maschinen scannen zu können. Das kann auch als Ausleihsystem verwendet werden. Maschinen sollen über NTAG oder QR Code gescannt werden. So kann unser System auch für Anleitungen verwendet werden.

Odoo soll über unser Audit Log gefüttert werden. Odoo ist ein ERP System

Uber das Audit Log können die aktuellen Ereignisse ausgelesen werden. Daruch kann eine Abrechnung erstellt werden.

Reservieren von Maschinen soll möglich sein. Wir wollen kein Schedule Plan für eine Maschine erstellen und verwalten. Machinen Watching wäre im Client sinnvoll. Maschinen sollen nur für einen bestimmten Zeitraum reserviert werden, also für den Weg zu Space nicht von wem anders für 5 Studen genutzt wird. Da Maker nicht plaungsorientiert arbeitn, sondern Impuloriertier, sehen wir nicht die notwendigkeit Reservierung für die nächste Woche vornehmen zu müssen. Außerdem sollen Maschinen nicht blockiert werden, durch solche Reservierungen. Bei einer Reservierung kann ein Admin auch die Maschine an wen anderes übergeben oder selber nutzten. Und es dauert immer länger, wenn jemand eine Maschine verwendent, da man nicht alles genau weiß wie lange es dauert. Und es soll auch nicht auf das Aufräumen verzichtet werden. Maschinen können auch mit einer Abnahme erst wieder Verfügbar gemacht werden.

Wir können kein Zeitmanagment nicht leisten für alle Space Nutzer.

Reservierung sollte ein Cooldown haben, damit man nicht direkt wieder Reservieren kann.

Ldap ist nicht so wichtig

Space API und FabLabs.io ...

01.12.2020 // Zusammenfassung - Freies Meeting

Um einen Überblick für unser Projekt zu erarbeiten haben wir ein Meeting mit einer externen Person durchgeführt. Dabei war das Ziel unser Projekt jemanden ohne Vorkenntnisse zu erklären und verständlich zumachen, somit mussten wir alle Punkte die unser Projekt betreffen ansprechen. Aus den Aufnahmen wurden folgende Punkte zusammengefasst. Mit diesen Punkten soll eine Präsentation für die Vorstellungen unseres Projekts erarbeit werden.

24.11.2020 // Webseiten Text

FabAccess

Unsere Core Features

Föderation

  1. Nutzer aus dem anderen Space können ihre Karte auch bei dir verwenden
    • Nutzer sind bei dir Registriert, der Föderierte Space übernimmt die Authentifizierung für dich. (wie bei SSO)
  2. Nutzer aus dem anderen Space können ihre Karte und ihre Gruppen auch bei dir verwenden
    • Nutzer sind bei dir Registriert, wie bei 1. und du kannst die Gruppen des anderen Space bei dir Verwenden, wenn du zum Beispiel die gleichen Maschinen hast. Das spart Zeit bei der Einweisung und du und der andere Betreiber müsst nicht alles doppelt und dreifach erklären.
  3. Nutzer aus dem anderen Space können ihre Karte und ihre Gruppen auch bei dir verwenden. Die Abrechung für diese Nutzter übernimmt dabei der andere Space für dich.
    • So musst du dich nicht um die Abrechung für externe Nutzer kümmern. So kannst du und andere Space zum Beispiel gesammlete monatliche Differenzrechnungen abrechnen. Das spart Zeit bei der Buchführung und deinen Nutzer können auch Ihre Rechnungen besser im Blick behalten.

Maschinenverwaltung

Nutzerverwaltung

SmartCard

Self Hosted

Automatisiere deine Verwaltung

Erweiterbarkeit

Features

18.11.2020 // Stellenausschreibung - SHK

Wir suchen Unterstützung für unserer Projekt "FabAccess"

Wer sind wir und was tun wir?

Wir sind eine Gruppe von Studierenden, die in Zusammenarbeit mit Betreibern und Mitarbeitern von FabLabs und Makerspaces, Software und Hardware zur Automatisierung der Verwaltung erarbeiten und umsetzen.

Wir arbeiten seit September an der Umsetzung des ersten Projekts "FabAccess". Durch dieses soll der Zugriff und die Steuerung von Maschinen automatisiert werden.

Für diese Umsetzung brauchen wir Unterstützung. Wir haben mehrere Aufgaben, die wir im Rahmen einer studentischen Hilfskraftsstelle auszuschreiben.

Leider können wir nur eine Person engagieren. Für eine Bewerbung wähle eines der Themen aus und bewirb dich darauf bei uns.

Du findest uns unter fab-access.org

Schicke uns deine Bewerbung an contribute@fab-access.org

1. Python API Library

Wir schreiben unsere eigene API in Cap'n Proto für unseren Server. Dafür benötigen wir jemanden, um für die API eine Python Library zu schreiben, um damit Befehle an unseren Server zu senden oder Daten davon abzurufen. Hierfür würden wir gerne die APIs von FabLabs.io und SpaceAPI.io anbinden, um automatisiert die Ausstattung und den Öffnungsstatus des FabLabs an diese Seiten zu übermitteln.

Skills:

2. Rust ABI Anbindung

Wir schreiben unsere eigene ABI zum Anbinden von verschiedene Sensoren und Aktoren, um diese dann über unseren Server zu steuern. Hierfür würden wir gerne unser Sortiment an unterstützen Sensoren und Aktoren erweitern. Wir suchen jemanden, um für folgende Aktoren und Sensoren eine Anbindung zu implementieren:

Skills:

16.11.2020 // Themen für eine SHK Stelle

Python

FabAccess-API in Python -> damit SpaceAPI.io oder FabLabs.io anbinden Package das erweiterbare Abstraktion für unsere API liefert Program das damit dann SpaceAPI.io & FabLabs.io füttern geht

Accounting anbinden

C#

=> UI bauen (Xamarin)

C# + Rust

Authentifizierung

Jeweils PoC Implemtentation in BFFH(Rust) und eventuell in Borpin(C#) und eventuell PoC Reader(C/C++)

Rust

=> Sensoren + Aktoren

=> SQL/LDAP Adapter für Nutzer etc.

Elektrotechnik

C/C++

generische Firmware STM32 ESP32

19.10.2020 // How to Prototype Fund

Was ist zu tun, wenn das Finanzamt die Tätigkeit als gewerblich eingestuft hat?

Solange noch keine Steuernbezahlt wurden kann das Finanzamt die Einstufung der Tätigkeit als gewerblich noch zu freiberuflich ändern. Dafür soll eine Nachricht, in der steht, dass man der Meinung ist, dass es sich hierbei um eine freiberufliche Tätigkeit handelt und eine Begründung dazu, sowie ein entsprechender Nachweis. Für die Prototype Föderung wäre das der Zuwendungsbescheid des DLR.

Leider ist das Finanzamt öfferts der Meinung, dass es sich bei freiberufliche n Tätigkeit um folgende handelt:

Freiberufler arbeiten selbstständig und eigenverantwortlich. Ihre Tätigkeit kann erzieherischer, schriftstellerischer, unterrichtender oder wissenschaftlicher Natur sein.

Dabei wir die Ausbildung für die Tätigkeit vorrausgestzt. Da man die Tätigkeit als Software Entwickler aber auch ohne abgeschlossene Ausbildung ausführen kann. Gibt es Gerichtsurteile, die die Tätigkeit als "Autodidakt" in IT Berufen anerkannt haben.

16.10.2020 // Contribute - Borepin

Contribute - Borepin

On Windows

  1. Install Visual Studio 2019 download Visual Studio
    • with Xamarin
    • with UWP
    • with .NET Desktop
  2. Install GTKSharp for Windows download GTKSharp
  3. Clone Borepin download Borepin
  4. Load Borepin
  5. Build Borepin

If Step 5. Build Borepin is failing because of GTKSharp, it could help to restart your PC.

Build GTK Project

  1. Install mono, gtk-sharp, msbuild, nuget 1.1 Debian based

    $ apt install mono-complete, gtk-sharp2, nuget

    1.2 ArchLinux based

    $ pacman -S mono, mono-msbuild, gtk-sharp-2, nuget

  2. Clone Borepin

    $ git clone https://gitlab.com/fabinfra/fabaccess/client.git

  3. Build Borepin

    $ cd client
$ msbuild -t:Borepin_GTK

  4. Run Borepin

    $ mono ./Borepin/Borepin.GTK/bin/Debug/Borepin.GTK.exe

You can also use Rider or monodevelop as an IDE for development on Borepin

Testing

We use NUnit for testing.

15.10.2020 // Team-Meeting 15.10.2020

tags: Meeting

Themen

  1. Studenzettel

  2. Audit Log Joris wollte wissen, wie das aussehen wird, damit er das mal an seine ERP Software anbinden kann. Eine Erweitung von SysLog EventLog maschinenlesbar

  3. FabReader

    • TLS mit fixen Key
    • Key wird über eine Master-Card ausgestellt
    • JSON ist fertig Joris schickt uns ein Exemplar zu zum testen

  4. NFC Lib

    • Protieren nach Rust
    • PICC ChangeKey fehlt noch
    • CMAC ist noch nicht implementiert
    • Testing muss nachgezogen werden

  5. Capt'n Proto API

    • Funktioniert der Vorschlag auf GitHub
    • Was muss noch getan werden

Tagets:

  1. Kooperationsvertrag Mail an Lewkowicz

  2. PrePaid Gregor kümmert sich.

  3. Coaching Montag Meeting nachfragen

13.10.2020 // DESFire Protokoll

LibLogicalAccess

Müssen wir uns mal anschauen, da die das können, was wir wollen

Bytes

APDU Commands

APDU Responses

APDU responses will first contain the data followed by two status bytes.

Instructions DESFire (used inside ADPU)

CLA = 0x90 APDU Sturuktur -> ISO/IEC 7816-4 Befehle -> DESFire

Instructions ISO/IEC 7816-4 (nativ, aber von DESFire unterstützt)

CLA = 0x00 APDU Sturuktur -> ISO/IEC 7816-4 Befehle -> ISO/IEC 7816-4

Instruction ISO 14443-3

Status Codes

from https://github.com/JavaCardOS/pyResMan/blob/master/pyResMan/DESFireEx.py#L54 which, has it from https://github.com/jekkos/android-hce-desfire/blob/master/hceappletdesfire/src/main/java/net/jpeelaer/hce/desfire/DesfireStatusWord.java

Files

Not shure yet what these constants do.

crypto operations

File types

Transmission modes

Getestet Reader und Treiber

ACS ACR122U-A9 | Microsoft Usbccid-Smartcard-Leser (WUDF) | Windows 10

13.10.2020 // Mitschnitt - OTA Proof-of-Concepts

connected
send 901a0000010000
recv a1bf8c11e96c9e4491af
RndA: eba87149d88ced0d
send 90af000010e055e9553cbfd8ae34cb7e0b9051bd4e00
recv 83ee10665e78da619100
send 90fc000000
recv 56730aec09169b2e9100
send 901a0000010000
recv 18e7f105cdfc574291af
RndA: 0278d460c6aa4af4
send 90af000010ac299e117b1c7eeb8984737978c546a800
recv b36cebe94cee71799100
session_key: 0278d46084f2ccea
iv: 0000000000000000
send 90ca000005eeffc00b8300
recv 89bad4f6f92dbc479100
session_key: 0278d46084f2ccea
iv: 0000000000000000
send 905a000003eeffc000
recv 9100
send 90aa0000010000
recv eda2aa1582cc7252d9bf19a330d4a9d191af
RndB_Enc: eda2aa1582cc7252d9bf19a330d4a9d1
RndB: 482ddc54426e6dee560413b8d95471f5
RndA: bc14dfde20074617e45a8822f06fdd91
send 90af0000207c2f74c3df09a484fc71e6e19b5ba3523a69b853cd91c6d603a1d714d8c3784800
recv b704f5283f60a82869e9252732a9f6ae9100
RndA_Enc: b704f5283f60a82869e9252732a9f6ae
changing key #00 to 45eeb8338ae8f49a032e85bb11143530
hdr: c400
cmd: c40045eeb8338ae8f49a032e85bb1114353010
cryptogram: 45eeb8338ae8f49a032e85bb111435301095c3894b0000000000000000000000
session_key: bc14dfde482ddc54f06fdd91d95471f5
iv: 00000000000000000000000000000000
cryptogram_enc: c4dc9ae48dd8a8073f7f9e9159335f29d16637cf3db18f982180f0b4de5d7a86
send 90c400002100c4dc9ae48dd8a8073f7f9e9159335f29d16637cf3db18f982180f0b4de5d7a8600
recv 9100
send 90aa0000010000
recv 189aa068a47e2f21ec81b1bc39f719d891af
RndB_Enc: 189aa068a47e2f21ec81b1bc39f719d8
RndB: 44c29525f6e679c0fea16b44d1af57e7
RndA: 3a100d71772cbf182c307691bc63d9ea
send 90af000020cbe7fc1f24ba588eb6a6562f92d0d74d9acd7af44e70e300df24a47ce377894500
recv 9607d533b5e018e51e33eea26f2b0a379100
RndA_Enc: 9607d533b5e018e51e33eea26f2b0a37
changing key #01 to 8db1f942f2d7cc82f6fa1486a30f8c12
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90c400002101619db367d23d64798871530300f5802ea9d55be543569934f5c47382d9075fbe00
recv da11d391cae880d39100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
changing key #02 to 77611d170c449df6f294c48581ab315d
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90c40000210234dfb57fd4aa1958244b415d098f96c571e0adf96bb3a5a01cb41d605e3d32cc00
recv 301e8cc99fe418549100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90cc0000110103102000000000ffff0000000000000000
recv 9fe32c9db79aae139100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90cc0000110203102000000000ffff0000000000000000
recv 014f0d71b8b85ceb9100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
done
websocket connection closed

05.10.2020 // QR-Code/NTAG Identifizierung

Ziel

Ziel dieses Features soll es sein, eine Identifizierung von Gegenständen über QR-Codes zu ermöglichen (bsp.: zum Ausleihen von Werkzeug, benutzen von Tischen).

QR-Codes oder NTAGs können an Gegenständen befestigt werden, welche dann über Borepin gescannt werden können und dann der Gegenstand ausgeliehen/genutzt werden kann.

Es wird also nicht für jeden Gegenstand ein Card Reader benötigt, dies übernimmt dann Borepin auf dem Handy des Nutzers.
Es kann auch ein zentraller PC zum Ausleihen von Gegenständen bereitgestellt werden, der dann mit einer Kamera und einem NFC Reader ausgestattet ist über den die Nutzer dann das machen können. Dafür müssen keine Nutzerdaten auf diesem PC gespeichert werden, sondern der Nutzer nur seine Karte auf den Reader legen.

Auf dem QR-Code / NTAG wird eine UID + Domain gespeichert, so können auch Externe dieses System nutzten.

Bei der NTAG Verwendung kann über RFID Scanner Tore (Warensicherungsanlage) so auch Diebstahl verhindert werden.

05.10.2020 // Audit Log

tags: Feature

Ziel

Ziel dieses Features soll es sein, dass Änderungen im BFFH als Log über eine interne Schnittstelle ausgegeben werden und von dritten Anwendungen ausgewertet werden können (bsp.: zur Abrechnung).

An das Audit Log können eigene Komponenten angebunden werden, die dann mit den Daten zum Beispiel ein Odoo System zur Abrechung befüllen.

Die Verteilung könnte über einen MQTT Broker erfolgen ???

05.10.2020 // Kartenverwaltung

tags: Feature

Ziel

Ziel dieses Features soll es sein, dass jeder Nutzer eine eigene Smart Card erhält, mit der er sich an allen Endpunkten anmelden kann.

Als Kartenlösung verwenden wir Mifare DesFire EV2 Karten. EV2 Karten haben Rolling Keys. Die Kommunikation zu der Karte erfolgt nur zwischen Karte und BFFH (Backend), der Reader dient nur als Proxy. Je Nutzer können eine oder mehrere Karten hinterlegt werden. Die Karten können bei Verlust gesperrt werden. Der Space der die Karte ausgibt hat als einziger den Master Key der Karte und es wird nur eine Application mit eigenen Keys benötigt, somit können die Karten auch von anderen Systemen verwendet werden. Externe Spaces müssen keine eigenen Karten ausgeben, sondern die Nutzer können ihre Karte überall anmelden.

Die Karte wird als primäre Identifizierungs und Authentifizierungs Methode genutzt. Man benötigt kein Handy, um sich zu authentifizieren. Zur Authentifizierung wird die OTA Implementierung von Mifare DesFire verwendet. Dadurch erhält der Reader, also das Endgerät, keine Schlüssel für die Karte des Nutzers. Somit kann auch über einen entfernten Space die Karte authentifiziert werden, ohne das der lokale Space den Schlüssel benötigt.

Nutzer können Maschinen über diese Karte nutzen oder ausleihen.

FAQ

Warum verwendet ihr keine Mifare Classic Karten?

Aus Gründen Einfach Nein!

Wie werden neue Reader angemeldet?

Mit einer MASTER Karte werden die READER authentifiziert und erhalten darauf ein Zertifikat vom Server womit jede weitere Kommunikation authentifiziert wird.

Reader authentifiziert sich mit einem TLS Two-Way Handshake gegenüber dem BFFH.

Was steht auf der MASTER Karte?

Es gibt zwei Möglichkeiten

Muss

  1. Karte enthält ein Zertifikat
    • Domain für BFFH (Steht auch im Zertifikat)
    • Zertifikat mit dem der Reader sich anmelden kann
  2. Karte dient als Authentifizierung
    • Domain für BFFH
    • Karte kann sich authentifizieren

Welche Verschlüsselung verwenden wir für die DESFire Karten?

AES

01.10.2020 // Kooperationsvertrag

Kooperationsvertrag

28.09.2020 // Prototypefund Monday Update - 28.07.2020

tags: MondayUpdate

FabAccess

Done:

Doing / Plan to do this week: Server:

Client:

Infrastructure:

Challenges:

Motivation:

21.09.2020 // Prototypefund Monday Update - 21.09.2020

tags: MondayUpdate

Done:

Doing / Plan to do this week: Server:

Client:

Infrastructure:

Challenges:

Motivation:

21.09.2020 // Tooling für das FabAccess Team

Kommunikation

Wie wird untereinander kommuniziert?

Konferenzen

Chat

Filesharing

Wie werden Dateien ausgetauscht?

Large Data

Code

Creating

Wie wird gemeinsam an neuen Ideen gearbeitet?

Text Based

Visual Based

Projektplaung

Wie werden Aufgaben und Anforderungen geteilt?

Projektplanung

Aufgabenplanung

Kalender / Zeitplanung

Dokumentation

Wie wird dokumentiert?

allgemeine Dokumentation

Code-Dokumentation

Website

07.09.2020 // Monitoring

tags: Feature

Ziel

Ziel dieses Features soll es sein, dass der Zustand jeder Maschinen überwacht werden kann.

Die Zustände der Maschinen sind öffentlich einsehbar oder nur für registierte Nutzer. Der Nutzer kann so erkennen, ob eine Maschine belegt ist. Der Betreiber kann sehen wer die Maschine gerade nutzte und von wem sie als letztes benutzt wurde. Grafana Template bereitstellen. Nur Betreiber können den Nutzer sehen.

Performance/andere Metriken aus BFFH exportieren Öffentliche Metriken für Prometheus exportieren.

Alle Maschinen Einträge und deren Spezifikation sind öffentlich einsehbar und können an fablabs.io übertragen werden.

07.09.2020 // Nutzungs- / Nutzerverwaltung

tags: Feature

Ziel

Ziel dieses Features soll es sein, das Nutzer über das BFFH verwaltet werden können und diese Berechtigungen erhalten.

05.09.2020 // Gespräch mit Joris 05.09.2020

05.09.2020 // Features zur Diskussion

tags: Feature

04.09.2020 // Offene Fragen

tags: Questions

Welche Systeme gibt es bereits? Wie sind solche System aufgebaut?

04.09.2020 // Föderation

tags: Feature

Ziel

Ziel dieses Features soll es sein, dass FabLabs untereinander föderieren können, ohne ein gemeinsamme FabAccess Instanz zu nutzten.

04.09.2020 // Maschinenkontrolle

tags: Feature

Ziel

Ziel dieses Features soll es sein, dass Maschinen über das BFFH ein und aus geschaltet werden können, sowie ihren jeweiligen Status melden können.

04.09.2020 // Föderartions Konzept

  1. tags: Konzept

Wie wird die Berechtigungsfreigabe für Maschinen in andere FabLabs übergeben? Gibt es hierzu eine Berechtigungsmartix oder übergeodrnetet Gruppen. Wenn in einem anderem FabLab eine Berechtigung erworben wird, wie werden diese gespeichert?

Whitelists für Domains

Modi der Föderation

Nutzerdatenübertragung

Nutzerinformaton

Authentifizierung in der Föderation

Space A: Ein FabLab Space B: Das FabHome des Nutzers Space A föderiert mit Space B und der Nutzer hat 2FA eingeschaltet.

Karte->Reader: Hier bin ich!
Reader->Space A: Karte möchte sich Authentifizieren
Note over Space A: Föderiere ich mit Space B?
Space A->Space B: Diese Karte möchte sich Authentifizieren.
Space B->Karte: OTA
Note over Space B: Nutzer kann Authorisiert werden
Karte->Space B: OTA
Space B-->Reader: Warte auf 2FA
Space B->Nutzer: 2FA: Ist das eine legitime Authentifikation?
Nutzer->Space B: Ja, ist es
Space B->Space A: Der Nutzer ist Authentifiziert!
Note over Space A: Aktoren ausführen.
Space A-->Reader: Nutzer ist Authentifiziert!

Zwei-Faktor-Authentifikation

Glosar

Space.png

Wie wird die Nutzungsbedingungen der einzelnen Spaces an den Nutzter weitergegeben? Wer könnte für Haftungsfragen aufkommen. Wie werden Berechtigungen gehandhabt, wenn Space A eine Berechtigung ausstellt, wo der Home Space B ist und Space B mit Space föderiert und dann die Berechtigung annerkennen soll von Space A.

Für den Anfang nicht wichtig aber später sehr. Welche vertraglichen Regeln müssen für eine Föderartion mit FabAccess müssen festgehalten werden?

11.08.2020 // August-Call Nr. 1 Fab-Access

Geschobene Themen aus dem Juli-Call Nr. 1:

Link zum vorherigen Protokoll:
https://pad.gwdg.de/USEMMX9ZQTKwoSOlMd1eyQ

Hardware-Kommunikations-Fragen (Joris)

Lastenheft vorstellen / durchsprechen.

Fragen(Joris):

Anforderungsliste:

allgemeine Fragen:

Sonstiges

21.07.2020 // Themensammlung Juli-Call FabAccess

Geschobene Themen für den Juli-Call Nr. 2 / August Nr. 1:

Hardware-Kommunikations-Fragen (Joris)

Lastenheft vorstellen / durchsprechen.

Zusammenfassung Juli-Call Nr. 1:

Tooldiskussionen

Projektmanagement

Erreichbarkeit

Doku

… wo schreiben / pflegen?

Architektur

Stand/Pläne PrototypeFund

Hardware

Ansätze / Stände

juli-call-1.jpg

juli-call-2.jpg

juli-call-3.jpg

juli-call-4.jpg

Stand FH Bocholt (tbd)
juli-call-5.png

24.06.2020 // Call zu Werkstatt-Zugangssystemen 2020-06-24


Teilnehmer:

Marcio
Max
Tasso (tasso.mulzer@beuth-hochschule.de)
tom

Marcio: Baut seit ca. 10 Jahren offene Werkstätten / MakerSpaces - hat bemerkt, dass er immer wieder an den selben Dingen angestoßen ist. Es gibt wenige verwendbare / einsetzbare Tools. Hat letztes Jahr ein Projekt bei einem Förderfonds eingegeben, wurde als unterstützenswert angesehen und ist jetzt dabei.
Tom hat die Verbindung zu FabAccess hergestellt. Es gibt bestimmt viele Parallelen und Marcio hofft, dass wir uns zusammen tun können.

Etappenförderung - beim Erreichen von Zwischenzielen werden neue Tranchen ausgelöst. Betrag darf nicht genannt werden.

Marcio: Maschinenbau-Studium, BWL-Studium und Projektarbeit / Organisation von Projekten.
Team: Patrick (Prototyping Hardware / Software-Schnittstelle) / Hans (Elektroniker), Rouwen, Livio & Francois arbeiten bei der EFL? und helfen softwareseitig. Viel läuft auf Englisch, die Sprachbarriere existiert schon irgendwie.
Nicolai hilft beim Design, ist aktuell in Sidney und arbeitet von dort aus mit.
Elias? hat/betreibt/entwickelt ein ERP-System.
Aktuell Konzeption des Hardware-Teils.
Schnittstellen und Einbindung des ERP-Systems muss noch geschaut werden. - es gibt eine API, das muss aber eben zusammengebracht werden.

06.03.2020 // Probleme die wir im Backend noch lösen müssen

IdP fuer FabAccess

Was wollen wollen wir allen zu externalisieren erlauben:

optional = nur wenn wir einen Anwendungsfall finden

<TMu;2020-03-04>Ja … Gruppen lowPrio optional, wenn überhaupt. … alles grundsätzlich nur lesend (Passwort-Ändern für HS-Account aus FabAccess brauchen wir tendenziell nicht).
“Eigene” User sollten natürlich ihr Passwort schon bei Gelegenheit mal ändern oder wiederherstellen können.</TMu;2020-03-04>

Problem: Merging

Es gibt tendenziell mehrere Datenquellen für Benutzer. Wie werden Collisions gelöst?
Idee 1: Es gibt eine fixe Policy. (z.B. Intern ist wichtiger)
Idee 2: Uniqueness check beim einfuegen von DB => Einfach wenn AuthToken immer lokal gelagert sind und nicht extern

<TMu;20200304>Jira lässt mehrere Authentication-Quellen zu - kopiert allerdings das komplette LDAP-Verzeichnis beim Einrichten. Find ich weniger schön. Leihs hat das besser gelöst … lässt bedingt auch mehrere Quellen zu (unterschiedliche Quellen haben unterschiedliche Login-Seiten) … holt die Nutzerdaten aber nur beim ersten Zugriff aus LDAP --> Nur Nutzer in der lokalen UserBase, die auch wirklich da waren statt “alle der Hochschule!!”</TMu;2020-03-04>

Inventar aus Leihs

Was sollen die Vorteile sein? Muss Daten live sein oder reicht es mehr oder weniger regelmäßig zu syncen?

<TMu;2020-03-04>Live wär schon schön … es passiert relativ häufig, dass jemand mit ${Ding} vor mir steht, ich es schnell eintrage und ihm wieder nur Nutzung in die Hand drücke.
Aus Leihs fallen als Formular hübsche Leihverträge und die Inventarisierung von (teilweise ausleihbaren) Geräten und Maschinen ist für das Labor echt passend gelöst - besser als alle ERP- oder sonstigen Inventar-Systeme.</TMu;2020-03-04>


06.03.2020 // Diskussion in der Telegram-Gruppe des VoW am 25.02.

Genannte Software-Schnittstellen

ERP

sonstige

Genannte Endgeräte

Sonstiges

Hackathon am 17. bis 19.04. in Dortmund wird erwartet.

18.02.2020 // Hackathon, 07.02.20

Strukturiert nach: https://www.mendix.com/de/blog/eine-praktische-anleitung-fur-den-product-canvas/

Product Vision Board

Abgrenzung

Zur Diskussion

Fragen zur Zielgruppe

Product Canvas

Personas

User Journeys

Technische Lösungen

To-Dos:

Zusammenfassung 08.02.

18.02.2020 // JitSi Call 18.02.

Teilnehmer:

Call

Jira wird eingerichtet (am Donnerstag)
Ziel ist, ADRs “herausfallen” zu lassen.

Sprache: TypeScript und Rust sind noch drin -->
Wenn komplett modular: anders.
Diskussionsbedarf für “anders als NodeJS und Rust”: …
Frage: Was braucht die Zielgruppe??
Antwort: User werden eher nicht an der Infrastruktur-Software bauen. --> Prio, dass Nutzer Anpassungen vornehmen können ist eher klein. Admins wollen nur installieren, haben keine Zeit zum bauen.

Das deutet irgendwie auf einen “Kern” hin, in dem viel fertig (konfigurierbar) vorhanden ist… gerne modular erweiterbar.

Ziel: Waagen sollen z.B. abfragbar sein. --> Modular.
Türen aufmachen usw. --> Monolithisch.

Waagen sind “Verbrauch von Werten” --> kann im “Kern” gebaut werden.

Was sind die ersten 2/3/4/5 UseCases?
<dequbed/Marcus>: Maschinen verwenden - Berechtigungssystem
2 Arten: reservierbar / one-time-use / Berechtigungen
Abrechnung … wurde x min. verwendet - kostet y.

Ansatz für heute:
Was haben wir bisher gemacht --> Wie kommen wir daraus sinnvoll zu einer Architektur?

Sprache klären oder nochmal aufschieben? --> Aufschieben.
Mit welchen Beweggründen haben wir was gemacht? … aufgeteilt in Frontend / Backend.

Fabian: Screensharing.
Backend: TypeScript / Node
Anforderung war: Generell erst mal anfangen, Zugangskontrolle zu automatisieren. Bisher: viele Eigenbaulösungen mit ESP / Reader / Türschlössern / Relays / … FabLab ist aber versichert, daher ist selbstgebaute Hardware nicht gern gesehen. Es gibt aber viel HomeAutomation-Hardware von der Stange, die das Problem an der Stelle lösen kann.
–> Schaltbare Steckdose finden und die anbinden.
Auf ein Protokoll einschränke ist doof --> wie können wir viele Protokolle mit wenig Aufwand einbinden? --> OpenHab2 mit RestAPI, um Aktoren anzusprechen.
Andere FabLabs nutzen odoo als UserBasis und zur Abrechnung. User / Booking / Rechnung / …
–> github.com/faaaaabi/fablab-api-gateway

github.com/faaaaabi/fablab-access-app
App: ReactNative (FaceBook-Frontend-Framework)
Nicht nur WebApp, sondern native.
App fragt Karte, kann Maschinen einschalten die er darf --> gibt Backend bescheid --> das schaltet über OpenHAB.
Räumlichkeiten sind wichtig, weil verschiedene Tablets verschiedene Maschinen schalten können.
Angedacht: 2FA

fabaccess.bian-meyer.de/
React-App. Kann Berechtigungen definieren, odoo hat nur Checkbox für “Hat Sicherungseinweisung”, odoo soll aber nur Stammdaten pflegen.
Berechtigungen sollen ins Backend.
Dependencies: Frameworks, xpress? analog zu Django bei Python. Odoo / OpenHAB / … aber nicht als Dependency, sondern mit abstraktem Interface implementiert.
Kommunikation zwischen Backend / OpenHab: REST; Backend / odoo: XML

RoseGuarden:
vor ca. 3 Jahren angefangen mit V1
Angular-App als Frontend. Backend aus Python, monolithisch.
Primäre Anwendung: Türen. Geräte nicht so wichtig. Viele Vereine, nicht zwingend FabLabs.
Hochschulen / größere MakerSpaces: Geräte … kleinere (haben keine Geräte) daher eher Türen.

Basis: RaspberryPi, liefert FrontEnd. Knoten synchronisieren sich über RestAPI.
Knoten die ausfallen bringen das System nicht durcheinander.

RoseGuarden 2:
ServerAnsatz wäre besser gewesen. Sollte Fernwartung zulassen. Ist gar nicht so viel anders als RG1.
Backend: modular, in Workspaces organisiert. mit 2FA und Pin lässt sich die Tür öffnen.
Neben Türen gab es den Ansatz, dass sich User verwalten lassen müssen.
Viel an der Hardware geschraubt “polling über REST”
FrontEnd: VueJS (React / Angular / Vue)
PythonCode - definiert Actions und Views einfach und modular. Kann evtl. “krachen”, wenn das Interface nicht ausreichend generisch ist.

ESP: RFID, Display&Touch, kann Relay schalten. Focus war darauf.
Frage: Wie löst das Modulsystem Abhängigkeiten zwischen Modulen auf?
Antwort: Bisher nicht notwendig, daher nicht implementiert. “Ich möchte aus View a Action b aufrufen” ist möglich.
Kommunikation über ActionManager ist möglich, bisher keine Kontrolle / FailSafe von Abhängigkeiten.

Wenn Maschinen eingeschaltet werden, soll angezeigt werden: “Kuck, ob der Wiederanlauf-Schutz aktiv ist!” usw. um Verletzungen und Schaden zu vermeiden.
Ergänzung aus dem VoW-Treffen:
Fast jeder hat ein SmartPhone, Tablets sind teuer --> QR-Code an Maschinen. Aktionen über SmartApps.

dequbed: tmate.io
DFBH
cap’n proto als Stichwort …
Rest zugeschaut - Fazit: durchdacht, generisch, ziemlich cool. Kann man nicht so gut verkaufen, ist aber gut gemacht.
Cap’n Proto stellt sicher, dass Schnittstellen zwischen Sprachen funktionieren. Es werden Schemata definiert und zur Verfügung gestellt, die Nachrichten sind sprachübergreifend sichergestellt definiert.
Das Tool generiert sprachspezifischen Code, der die Schnittstellen einbindet.
Vergleichbar mit Protocol-Buffer, aber mächtigere RPC. Einfachere bidirektionale Interfaces.

Marcus: Muss RG1 fixen --> schaltet auf ListenOnly.

Wie bekommen wir hin, dass Fabian & Marcus bei dem coolen Shit, den dequbed “hingeworfen” hat mitkommen? – Busfaktor sollte 3 sein, nicht 1.

Zu klären: Kommunikation Front-/Backend
Varianten: Websockets / Server dazwischen.

Fabi: Für APIs, die wir nach außen zur Verfügung stellen, sollten wir auf REST setzen. Geringe Einstiegshürde.
0815-User kann mit Cap’n Proto jeweils Schnittstellen erstellen, die sie als Start nutzen können.
a) Dokumentation für User, die mit CP dann ihre Schnittstellen erstellen können.
b) Wir maintainen eine Python-Lib, die die Schnittstelle abbildet.

Modul-Implementation:
Bei V1.0: FabLab braucht Hue-Lampen.
MQTT ist im Kern eingebaut. Wir können MQTT sprechen. Du (externer User) schreibst in Python eine Implenentation, die nur Encoding macht … erstellst also eine Message, die von uns über MQTT versendet wird.
Wie können wir mit anderen Sprachen interagieren? - Ruby,C,Python,JS, … Kommunikation mit dem Kern soll möglichst einfach werden.

Aufwand ist “gigantisch” Code soll am Ende nicht mehr von uns geschrieben werden, sondern von Usern. Wir kümmern uns um alles, was im Kern stattfindet. Bieten EINE Schnittstelle an, aber nicht mehr.
Alles was kaputt gehen kann, muss in Rust geschrieben werden, damit ich wenigstens mitbekomme, wenn es kaputt gegangen ist.

Supergute Dokumentation ist extrem wichtig. Evtl. weniger Aufwand, Dokumentation für eine Schnittstelle gut zu machen als 10 Schnittstellen zu maintainen.

dequbed wünscht sich Backend mit 1 Schnittstelle zum FrontEnd.
Gedanken über die API machen.

Testweise, exemplarisch schauen, wie das mit der Anbindung Cap’n Proto funktioniert.
dequbed kann den (rudimentären) Server zum testen ins Netz werfen.

Lizenzen…
MIT - Copyleft … erhöht die Innovativität …
OSI-Lizenz ist Voraussetzung.
Ist (…teilweise …evtl.) von der öffentlichen Hand finanziert.
Gregor: APIs dürfen nicht kommerzialisiert werden. Alles andere … kann und soll diskutiert werden.

Wir machen eine Umfrage - stoßen eine Diskussion an … evtl. MultipleChoice-Umfrage in Telegram.
AGPL-3.0 GPL3/2 EUPL-1.1 LGPL-2.1 MPL-2.0 Apache2.0 BSD3-Clause MIT CC0

04.01.2020 // Materialsammlung 29.12.2019 @36C3

  1. Vorstellungsrunde der Anwesenden
  2. Erläuterung der bisherigen Aktivitäten und Hintergründe / Fragerunde
  3. Materialsammlung für eine Anforderungsliste

Zugang zu Räumen / Maschinen regulieren

Strukturierung des Betriebs

Abrechnung von Maschinennutzung und / oder anderen ${Dingen}

13.12.2019 // Protokoll Jit.si-Konferenz 09.12.19


Teilnehmer

“Morphologischer Kasten”

[OAS] [RoseGuarden] [BF2H]

MLP / MAP: Sinnvoll … nur, vermeiden dass das Skateboard mit dem Endprodukt vermischt wird & den ersten Eindruck “versaut”.

Entscheidungen: Konsens / Systemisches Konsensionieren

Programmiersprache:

<Fabian> Klare Empfehlung, Diskussion über Technologie relativ spät. Was sind die UseCases? … Was kann ich aus den UseCases ableiten, sinnvolle Technologien dazu zu finden.</Fabian>

<Marcus>+1 technische Features / Technologien ja … Programmiersprache als Basic früher.</Marcus>
<M V> Vorstellung der bisherigen Systeme … was kann man dort herausziehen? - ergibt sich daraus schon etwas?</M V>

<Fabi>Hilft Sprachwahl auf Meta-Ebene?</Fabi>

[…] Sprachdiskussion.

Fragen:

Bewertung (1: Am liebsten 4: Am wenigst liebsten X: VETO):

Frontend: Kevin / Marcus / Fabian /
Backend: Dequbed / Marcus / Fabian / Thee
Firmware Clients: Tasso / Dequbed / Thee

Ranking: Beliebteste Sprache? … Sprache die am häufigsten verwendet wird? … Was kann wer aktuell? … was machen viele? … was machen “die Guten”?

Kotlin - noch nicht so gewachsen wie Java
Java 9 - kaum Dokumentation, aber gewachsen.
Java 5 - viel Dokumentation aber nicht 2020.
Python Umstieg 2 zu 3 … relativ unproblematisch.
Python: Exceptions, daher potentiell instabil. Evtl. abfangbar mit Lint / CI
TypeScript … ist Javascript mit strikter Typisierung --> fängt viele Fehlermöglichkeiten ab. TypeScript != Node.js
Node kann threaden, erreicht gute Performance, JavaScript ist event-fokussiert, singlethreaded. Node kann zwar threaded, man arbeitet aber ähnlich wie im Browser.
Promises … gibt’s in TypeScript. Alles aus JavaScript + TypSystem. Java: geht, Python: geht (twisted?) … Rust: Standard-Feature

Fragen die noch zu klären sind…

Kuratiertes Framework vs. Erweiterbarer Monolith

Fabian:

Was soll beim 36C3 geschehen?

Geld beim VoW?!

Monolith / Modulsystem / FrameWork??

Monolithic vs. Modular (JavaScript/Node.js)
Simon Brown - Modular Monoliths

nächster Call

Doodle - lockerer, offener Termin noch vor Weihnachten? … ansonsten intensiver im neuen Jahr.

09.12.2019 // Grundlegendes

Zuverlässigkeit ist Hauptziel; wenn BF₂H als Schließsystem für Türen o.ä eingesetzt werden soll kann ein Crash bedeuten das nur noch das Backup-Personal mit Schlüssel in das Labor kommen kann.

Der laufende Wartungsaufwand sollte null sein. Einmal aufgesetzt sollte das System möglichst ohne Unterbrechung laufen können. Datenquellen wie Datenbanken sollten darauf ausgelegt sein nicht korrumpierbar zu sein, Fehlerquellen wie nicht überprüfte dynamische Konfiguration die durch Schreibfehler o.ä. im späteren Betrieb Fehler aufwirft sollte so gut wie möglich im Vorhinein überprüft werden. Upgradepfade von Versionen zu neueren Versionen sollten klar sein. Ein Versionierungsschema wie Semver oder PVP sollte verwendet werden und Integrationstests sollten explizit darauf ausgelegt sein Änderungen in dokumentiertem Verhalten ohne Versionsänderung als Defekt zu deklarieren.

Das System muss erweiterbar sein; insbesondere Anbindung an bereits vorhandene Schließsysteme sollte möglich sein ohne das grosse Änderungen im Kern vorgenommen werden müssen. Hier bietet sich tendenziell ein System mit zur Laufzeit ladbaren Modulen an.

Anbindung an andere externe Systeme — z.b. Authentifizierung/Autorisierung über ActiveDirectory / LDAP / SAML oder Abrechnung über ERP wie Odoo — sollten auch möglich sein, aber die Anzahl der Schnittstellen die benötigt werden ist tendenziell wesentlich geringer also ist hier der Vorteil von anwendergeschriebenen Modulen weniger groß bzw. fehlende Zentralisierung kann die Qualität der Schnittstellen senken; i.e. eine einzelne generische Schnittstelle für LDAP und AD ist wesentlich sinnvoller als mehrere für jeweils die eine Instanz in den jeweiligen offenen Räumen.

Spezifische Technologien

Frontend nicht im Umfang dieses Dokuments.

Design Backend

Sprachwahl: Rust. Bestes Kosten/Nutzen-Verhältnis für stabile Software. Weniger populär als Java/C#/Python/PHP/C++/C, aber das ist nur dann relevant wenn die Software im Basar-Stil von sehr vielen Leuten entwickelt wird die alle nur sehr kleine Änderungen beitragen. Sehe ich hier nicht als gegeben, eher wahrscheinlich ist das 80-90% des Codes von einer Handvoll Entwicklern geschrieben wird und nur Fringe-Code von “Externen” beigetragen wird.

Vorteile von Rust:

(* Rust hat “Exceptions” in der Form von panics. Diese sind aber anders zu sehen als Exceptions in z.B. C++ oder Python weil sie nur für schwere und nicht behebbare Fehler gedacht sind und auch nicht innerhalb einen Threads abgefangen werden können)

Kommunikation

Kommunikation zwischen Komponenten:

(P2P steht in diesem Kontext fuer Point-to-Point also Unicast, P2MP steht fuer Point-to-MultiPoint, also Multicast, nicht fuer Peer-to-Peer im Stil von BitTorrent o.ae.)

Sinnvolle Protokolle:

Netzwerkabstraktion wäre schön, aber HTTP löst die gegebenen Probleme schlechter als reines TCP, sollte also nicht verwendet werden.

Websockify für Web-basierte Frontends?
alt.: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

Verschlüsselung / Sicherheit

Backend mit Schliesssystemen

TLS ist ein extrem komplexes Protokoll, kann also vor allem für embedded Plattformen zu schwer werden. Zusätzlich bietet TLS uns keine Vorteile; die wichtigsten Eigenschaften des TLS-Stacks sind Aushandlung von Algorithmen und Zertifikatsvalidierung via PKI. Alternative: Nachrichten werden mit festgelegtem Algorithmus (z.B. Salsa20/Poly1305 oder AES256-GCM) verschluesselt. Beim erstmaligen Einrichten einen embedded Clients wird ein System-Key generiert, dessen public key auch dem Backend-Server bekannt ist und der für Authentifizierung des Clients gegenueber des Backend-Server genutzt wird.

Backend mit Frontends

Frontends werden auf wesentlich leistungsstärkeren Plattformen aufgesetzt sein. Vor allem bei lokalen Frontends ist TLS sehr sinnvoll.

Design Schliesssysteme

Primär Leistungsschwache, auf Kosten optimierte Hardware.
Oft gesehen: ESP8266, Arduino

Vor allem bei ESP8266 ist ein System wie NodeMCU sinnvoll. Das Protokoll zum Server / Crypto kann in C/C++/… implementiert werden, die Maschinen-spezifische Handhabung dann in Lua.

Misc.

Moduldesign

Spezifisch Kommunikationsmodule mit Schliesssytemen:

<!- vim: set spelllang=de: ->

09.12.2019 // Vorbereitung Jit.si-Konferenz am 09.12.19

https://meet.jit.si/oas

[OAS]
[Roseguarden]
[BF2H]

Agenda

Fragen?

Konsens?

Technologiefragen (hinzugefügt von mdrobisch)

Entscheidungsfindung

Hauptprogrammiersprache im Backend

Vorschlag Entscheidungskriterien zur Auswahl der Programmiersprache:

Rangfolge entspricht Priorität (1. Sehr Wichtig … n+1. nicht wichtig)

  1. Zu Verfügung stehende Manpower (im Moment), d.h. kurzfristig zu erwartender Geschwindigkeit der Entwicklung
  2. Zu erwartende Manpower/Entwickler, d.h. langfristige Entwicklung / Bestand des Projektes / Geschwindigkeit der Entwicklung
  3. Niederschwelligkeit für Einsteiger und nicht-Entwickler (Doku, Entwicklungsumgebungen)
  4. Zur Verfügung stehende relevante Bibliotheken
  5. Bestehende Projekte auf denen aufgebaut werden kann d.h. starten wir am Anfang oder in der Mitte und gibt es Hilfestellung beim einrichten Programmieren
  6. Technische Feature der Sprache (ggf. mit Mindestschwälle, Turing-Vollständig)

Bitte weitere ergänzen oder Prio ändern

Schnittstellen

Vorschlag Entscheidungskriterien zur Auswahl der Hauptschnittstelle:

Rangfolge entspricht Priorität (1. Sehr Wichtig … n+1. nicht wichtig)

  1. Erfahrung mit der Schnittstelle (im Moment)
  2. Interne Integrierbarkeit (nach innen, intern zwischen Komponenten des System bzw. bestehende Systeme, z.B. Bibliotheken, Bestandslösungen)
  3. Client/Hardware Integrierbarkeit (möglichkeit/aufwand Mikrcontroller und Clients)
  4. Externe Integrierbarkeit (nach außen, für externe/andere Systeme)
  5. Niederschweligkeit für Einsteiger (Doku, Verbreitung, Infrastruktur)
  6. Technische Feature der Schnittstelle

Bitte weitere ergänzen oder Prio ändern

Frontend

Angebundene Geräte (Clients/Mikrocontroller)

Fragen zu Rust

Fragen zum P2P-Ansatz


08.12.2019 // OAS 4 All

Grundidee des bestehenden Fabaccess Systems

Technologieentscheidung

Beruhen zum Großteil auf persönlicen Präferenzen. Daneben:

03.12.2019 // Roseguarden

Repositories (v2): https://gitlab.com/roseguarden
Demo: https://roseguarden.fabba.space/dashboard

Vorbetrachtungen

Projektinterne Werkzeuge

Im Folgenden werden die aktuell verwendeten digitalen Werkzeuge aufgeführt sowie eine kurze Begründung für deren Entscheidung.

Python

Für die Backend-Entwicklung

Nebenbemerkung Javascript für die Frontend-Entwicklung

Flask

Python-Framework für die Backend-Entwicklung

Vue

Für die Frontend-Entwicklung

Vuetify

Für die Frontend-Entwicklung

HTTP/S

Als Schnittstelle nach außen

Eigenentwicklung von Hardware

Systemdesign

Koordinator

Nodes

Authentifikation

Beispiele des Datenflusses

Freischalten neuer Karten im Büro

Gerät freigeben

Öffnen einer Tür

(Reader und Türsteuerung an verschiedenen Orten / Knoten)

Getränke kaufen

roseguarden Backend

roseguarden Frontend

roseguarden Hardware

Weitere Hardware

Interessante Hardware für später

roseguarden Firmware für die eigenentwickelte Hardware

Berücksichtigte/Angedachte UseCases (Features)

Offene Punkte

Historie von roseguarden

01.12.2019 // Mumble-Sitzung 26.11.19

Vorstellungsrunde:

36C3?

wer / was / wie viel / welche Perspektive ?

wer / was fehlt?

Geld

Weichenstellungen

Projekt

Technologien

Repo

Core-Sprache

Frontend-Sprachen

Hosting

Architektur

Benötigte Infrastruktur

Benötigte weitere Ressourcen

Nächster Termin

20.11.2019 // Open Access System_Dokument zum Verbundstreffen

Du möchtest Teil des Projektes werden? Melde dich bei Max

Hier geht es zum aktuellen Projekt-Dokuemnt: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ?view

Kurzvorstellung des Teilprojektes FabAccess

FabAccess ist ein Zugangssystem, das, basierend auf den verschiedenen Ansätzen und gemachten Erfahrungen der einzelnen Werkstätten, eine möglichst breite Nutzbarkeit ermöglichen soll. Ziel ist die Entwicklung möglichst objektbasierter und generischer Schnittstellen, die die diversen Bedürfnisse der Werkstätten abdecken.

Authentifizierungsmethoden: 13,56Mhz RFID-Karten und Pin, QR-Code über Nutzer-App

Specs:

Doku zum Workshop auf dem Verbundstreffen der Offenen Werkstätten 2019

Das Projekt sowie der aktuelle Stand wurde vorgestellt. Im Anschluss folgt das Feedback der Teilnehmenden:

Folgende Fragen wurden gegen Ende gestellt:

Wünsche / To-Dos:

Digitalisierung der Klebezettel, die von den Teilnehmern beschrieben wurden

Technologien/Tools die Werkstätten verwenden