\label{itm:anforderungen-jlo-1}\anf& Maschinen sicher schalten & Für jede Maschine muss ein Schaltkonzept hinterlegt werden können, welche auf die Eingabe von Sensoren reagiert, diese überprüft und mit den jeweiligen Aktoren agiert. & Core / GUI & EMFI-Chat \\
\label{itm:anforderungen-tmu-1}\anf& Einfache ``Maschinen'' abbilden & Es soll z.B. möglich sein, auch Tische / Schraubenzieher / ... abzubilden, die keine Einweisung und / oder kein Berechtigungssystem benötigen. & Core / GUI & Metapad (TMu) \\
\label{itm:anforderungen-tmu-6}\anf& Override & Es soll z.B. möglich sein, mit verschiedenen ``Master-Karten'' Maschinen direkt am Node ein- und auszuschalten. Auch wenn keine Netzwerkverbindung besteht. & Node & Erfahrung Card2Go (TMu)\\
\label{itm:anforderungen-tmu-7}\anf& Übergabe & Es soll möglich sein, innerhalb einer \emph{kurzen} Karenzzeit (z.B. 15 s) eine Maschine von einem Nutzer an einen neuen und dazu berechtigten Nutzer zu übergeben. Z.B. für Einweisungen ($\geq5\rightarrow1$) oder unkomplizierte Übergabe mit Übertragung der Verantwortung für Putzen und weiteres ($\geq3\rightarrow\geq3$) & Core / Node & Erfahrung Card2Go (TMu) \\
\label{itm:anforderungen-tmu-8}\anf& Abnahme & Eine abnahmepflichtige Maschine die genutzt wurde, muss erst von einem zur Abnahme Berechtigten (z.B. Stufe $\geq4$) abgenommen werden, bevor sie wieder von einem Nutzer der nicht zur Abnahme berechtigt ist (z.B. Stufe $\leq4$) in Betrieb gesetzt werden kann. & Core / Node & Erfahrung Card2Go (TMu)\\
\label{itm:anforderungen-tmu-2}\anf& Qualifikationsmatrix & Qualifikation der Kombination Nutzer-Maschine muss in z.B. 5\footnote{Das Stufenmodell soll mit sensible defaults voreingestellt, jedoch für die individuelle Berechtigungssteuerung auch durch die Administratoren in den Nutzergruppen auf die jeweiligen Bedürfnisse anpassbar sein.} Stufen abgebildet werden können und im Schaltkonzept berücksichtigt werden. & Core / GUI & MetaPad (TMu)\\
\label{itm:anforderungen-tmu-3}\anf& Nutzerhinweise ausgeben & Nutzer sollen z.B. auf abgelaufene Einweisungen hingewiesen werden und verst"andliche Fehlermeldungen erhalten, falls eine Aktion abgelehnt wird. & Core / GUI / Node & Metapad (TMu)\\
\label{itm:anforderungen-deq-5}\anf& Module & Zur Laufzeit ladbare Module mit denen zumindest neue Sensoren \& Aktoren hinzugef"ugt werden k"onnen & Core / Module & EMFI-Chat \\
\label{itm:anforderungen-jlo-2}\anf& Maschinen Monitoring & Überwachung von Aktivität und Eigenschaften(Stromverbrauch) von Maschinen & GUI & EMFI-Chat \\
\label{itm:anforderungen-jlo-3}\anf& Reservierung von Maschinen & Maschinen sollen {\em kurzfristig\footnote{Die kurzfristige Reservierung soll Nutzern ermöglichen, eine freie Maschine z.B. während der Fahrt zum Labor nicht zu verlieren. Es soll NICHT möglich sein, ``ein Handtuch auf die Maschine zu legen'' und potentiell nutzbare Maschinen aus der freien Nutzung zu nehmen und (aus welchen ehrbaren Gründen auch immer) für andere zu blockieren.}} von Usern reserviert werden können und sind dann entsprechend für andere User gesperrt & Core & EMFI-Chat (TMu)\\
\label{itm:anforderungen-deq-7}\anf& Blockieren von Maschinen & Maschinen k"onnen z.B. für Wartung oder geplante Veranstaltungen von Administratoren blockiert werden und sind dann für alle oder mit Ausnahme bestimmter User bis zur Aufhebung der Blockade gesperrt & Core / Node & EMFI-Chat \\
\label{itm:anforderungen-tmu-4}\anf& Hinweise zur Relation Zeit - Maschine abbilden & Es soll z.B. möglich sein, für eine Maschine einen Hinweis zu hinterlegen, der angezeigt wird wenn absehbar ist dass eine geplante Nutzung (3D-Druckauftrag) länger als bis \$\{Zeit\} dauern wird. & Core / GUI / Node & Metapad (TMu)\\
\label{itm:anforderungen-tmu-5}\anf& Nutzungsende ankündigen & Vor Ende einer geplanten Nutzungszeit soll in einem bestimmbaren Zeitraum das Ende der Nutzungszeit angekündigt werden (rückwärts-counter). & Core / GUI / Node & EMFI-Chat (TMu)\\
\label{itm:anforderungen-jlo-4}\anf& Öffnungszeiten festlegen & Das Schließsystem und die Maschinen sollen Nutzungszeiten haben, für einzelne Maschinen (z.B. 3D-Drucker) sollen Ausnahmen gesetzt werden können & Core / GUI & EMFI-Chat \\
\label{itm:anforderungen-jlo-5}\anf& Gruppieren von Maschinen & Maschinen sollen Gruppen hinzugefügt werden können, dabei kann eine Maschine in mehreren Gruppen sein & Core/GUI & TheJoKlLa \\
\label{itm:anforderungen-jlo-6}\anf& App orientierter Client & Es soll unabhängig alle von uns entwickelten Anwendungen in den Client eingebunden werden können & GUI & TheJoKlLa \\
\label{itm:anforderungen-jlo-7}\anf& Plattform unabhängiger Client & Der Client soll Plattform unabhängig sein. Primäre Windows, Android, iOS & GUI & EMFI-Chat \\
\label{itm:anforderungen-deq-8}\anf& Statusanzeige & Statusanzeige soll sowohl spezifisch f"ur eine einzelne Maschine als auch f"ur eine Gruppe von Maschinen m"oglich sein. In der Statusanzeige der Maschine soll schnell erkennbar sein, wer für die Maschine verantwortlich ist - bis die Maschine durch einen Benutzer mit der Berechtigung zur Abnahme der Maschine wieder freigegeben ist. & Core / GUI / Node & EMFI-Chat (TMu) \\
\label{itm:anforderungen-tmu-13}\anf& Logdatei & Sämtliche Ereignisse, die im Core erzeugt und ausgewertet werden, werden auf einer gut dokumentierten Schnittstelle als structured log ausgegeben werden. & Core & EMFI-Chat (deq) \\
\label{itm:anforderungen-tmu-10}\anf& Anzeige von Verantwortlichen & In der Statusanzeige von Maschinen soll schnell erkennbar sein, wer aktuell für eine Maschine verantwortlich ist. Bis eine reinigungspflichtige Maschine durch einen Benutzer mit der Berechtigung zur Abnahme der Maschine wieder freigegeben ist soll sie gesperrt bleiben. & Core / Node & Erfahrungen Card2Go (TMu)\\
\label{itm:anforderungen-deq-9}\anf& Authentifizierung & Authentifizerung von Benutzer passiert "uber SASL um erweiterbar zu bleiben & Core & Erfahrung mit Backends. \\
\label{itm:anforderungen-tmu-11}\anf& Schnittstelle zu externer Nutzerdatenbank & Wenn eine externe Nutzerdatenbank zur Verfügung (AD / LDAP / ...) steht, soll diese genutzt werden. Im Core werden dann nur zusätzlich notwendige Daten (Einweisungen / Berechtigungen / ...) über eine NutzerId verknüpft verwaltet. Diese Daten sollen nach einem DGSVO-konformen Löschkonzept gelöscht werden, wenn sie nicht mehr benötigt werden. & Core / GUI & Erfahrung mit Backends. (TMu)\\
\label{itm:anforderungen-tmu-12}\anf& Interne Nutzerdatenbank & Wenn keine externe Nutzerdatenbank zur Verfügung steht, soll eine interne Verwaltung der Nutzer über eine einfache Datenbank möglich sein. & Core / GUI & Erfahrung mit Backends. (TMu)\\
Bestimmte Sachen sind im Zusammenhang mit dem Gesamtsystem sinnvoll, sind aber unserer Meinung nach im Kern nicht richtig aufgehoben. Diese Dinge sollten besser extern\footnote{Non-Features können innerhalb von FabAccess, jedoch nicht im Kern sondern in externen Referenz-Modulen - oder auch in vollständig getrennten Projekten implementiert werden.} gel"ost werden.
\begin{longtable}{p{3cm}|p{6cm}|p{4cm}}
Stichwort & Anforderung & Alternative \\
\hline
User Monitoring & Nachvollziehen wann welcher Nutzer welche Maschine genutzt hat. & Wird "uber externe Loganalyse-Werkzeuge gel"ost. \\
Abrechnung & Abrechnung von benutzen Maschinen wie z.b.\@ Laser-Cutter. & Software wie Odoo ist f"ur sowas wesentlich besser geeignet. \\
\end{longtable}
\section{Ausgangssituation}
\subsection{Wie kam es zur Projektidee?}
Sowohl im FabUniverse-Netzwerk\footnote{Im FabUniverse-Netzwerk sind Akteure der FabLabs und MakerSpaces innerhalb von Hochschulen aus dem deutschsprachigen Raum vertreten.} als auch im Verbund Offener Werkstätten wurde Ende 2019 deutlich erkennbar, dass viele Akteure an ähnlichen Zugangssystemen arbeiten. Viele sehr spezifische L"osungen wurden sichtbar, aber keine, die Open Source sowie ausreichend generisch gebaut ist, um den unterschiedlichen Bedürfnissen vieler Werkstätten zu entsprechen.
Um die Aktivitäten an der Stelle zu bündeln, wurde gemeinsam durch die beiden Netzwerke das Projekt FabAccess bzw. die Gruppierung FabInfra ins Leben gerufen.
\subsection{Welches Problem ist aufgetreten?}
Zugangskontrolle und Management in Fablabs ist unzureichend automatisiert. Dadurch entsteht zum einen viel (unnötiger) Aufwand auf Seite der Betreiber von offenen Werkstätten, zum anderen könnten durch ein zuverlässiges System an der Stelle Gefahrensituationen verhindert und minimiert werden.
\subsection{Wie wurde damit in der Vergangenheit umgegangen?}
Es wurde eine Reihe von Fablab-/Makerspace-spezifischen Programmen entwickelt, die alle f"ur das Fablab speziell ausreichen aber nicht f"ur alle Labs ausreichen.
Teilweise wurden auch für spezifische Probleme geeignete Insellösungen eingesetzt, die jedoch auch nur einzelne Probleme lösten (z.B. Nuki als Tür-Öffner, der aber keine Maschinen absichern kann).
\subsection{Wieso besteht Handlungsbedarf?}
Das Finanzierungsmodell von kommerziellen Alternativen wie Fabman.io ist f"ur viele Makerspaces nicht erschwinglich.
Es soll in den offenen Werkstätten den Betreibern Arbeit abgenommen werden, damit sie ihre Ressourcen auf wichtigere Dinge konzentrieren können.
\subsection{In welche längerfristige Strategie soll das Projekt eingebunden werden?}
Im Verbund offener Werkst"atten organisierte Werkstätten; Netzwerk FabUniverse und damit deutschlandweit in Hochschul-FabLabs/-Laboren;
Spezifisch zunächst im FVM-Labor der Beuth Hochschule für Technik Berlin, ...
\section{Warum überhaupt FabAccess?}
% Was genau soll am Ende des Projektes entstanden sein?
% Woran wird der Erfolg im Einzelnen gemessen?
% Welche Messverfahren kommen zum Einsatz?
% Was muss passieren, damit die Lösung realisiert werden kann?
% Welche Termine gelten? - August.
\section{Zielsetzung gemäß der SMART-Kriterien}
Specific – target a specific area for improvement.
Measurable – quantify or at least suggest an indicator of progress.
Assignable – specify who will do it.
Realistic – state what results can realistically be achieved, given available resources.
Time-related – specify when the result(s) can be achieved.
\section{Produkteinsatz}
Unter welchen Rahmenbedingungen soll das Produkt zum Einsatz kommen?
(z. B. Temperatur, klimatische Bedingungen, Druck, Umfeld, etc.)
Von wem soll das Produkt bedient werden?
Was soll das Produkt unter welchen Rahmenbedingungen leisten?
Nutzung von Maschinen soll nur denjenigen möglich sein die eine Unterweisung oder vergleichbare Praxiserfahrung mit Maschinen dieser Art besitzen.
Maschinen können ohne Interaktion durch die Werkstatbetreibereingeschaltet werden wenn eine zugriffsberechtigte (befähigte und eingewiesene) Person das wünscht.
Pro Maschine sind die Berechtigungslevel 0-5 jeweils eine Rolle, die aus der unterliegenden erbt.
Jede Rolle definiert die f"ur das Level spezifisch notwendigen Berechtigungen.
Ein Mitglied mit Ausweis ist an den meisten Maschinen automatisch Teil aller Rollen-0\footnote{Ausnahme gef"ahrliche Maschinen wo auch beim zusehen Gefahr besteht (Lasercutter?)}.
Berechtigung $-1$ enspricht einem Nutzer der in keiner der 6 Rollen eingetragen ist.
Nach Anforderung~\ref{itm:anforderungen-deq-5} kann Kommunikationscode um mit spezifischen Sensoren und Aktoren zu interagieren in Form von zur Laufzeit ladbaren Modulen hinzugef"ugt werden. Diese Module sollten zumindest in den Programmiersprachen Python und Lua schreibbar sein und an gut dokumentierte Schnittstellen andocken können.
Nach Anforderung \ref{itm:anforderungen-deq-4} und \ref{itm:anforderungen-deq-3} bietet FabAccess keine eingebaute M"oglichkeit zur Abrechnung von Maschinenstunden oder zur minut"osen Nachverfolgung der Belegung von Maschinen im Nachhinein.
Id & Stichwort & Anforderung & Kategorie & Quelle \\
\hline
\label{itm:anforderungen-jlo-10}\anf& SSO / Weitergabe Möglichkeit von Usern & Zu FabRega und FabLock Systemen. Vielleicht direkt Keycloak nutzten & Core & TheJoKlLa \\
\label{itm:anforderungen-jlo-9}\anf& Reservierung von Maschinen & Maschinen sollen von Usern reserviert werden können und sind dann entsprechen für andere User gesperrt & Core & EMFI-Chat / Beuth \\