My changes

FabAccess_Lastenheft.tex

@@ -9,7 +9,7 @@
 \setsansfont{D-DIN.otf}[ Path=./fonts/ ]
 
 \title{EMFI-Lastenheft}
-\author{tasso.mulzer}
+\author{FabInfra Team}
 \date{March 2020}
 
 \begin{document}
@@ -24,15 +24,16 @@ Nutzern der Maschinen soll klar sein, dass sie für das Putzen nach der Nutzung
 
 \section{Laborsteuerung}
 
-Software wird zur Verwaltung offener Werkstätten eingesetzt und soll dort möglichst viele Jobs wegautomatisieren.
+Software wird zur Verwaltung offener Werkstätten eingesetzt und soll dort
+möglichst viele Jobs wegautomatisieren.
 
 
 \subsection{Maschinenkontrolle\footnote{Zutritt zu Räumen wird wie eine Maschine behandelt. Das System soll auch den Zutritt zu Räumlichkeiten verwalten können}}
 
-Nutzung von Maschinen soll nur denjenigen möglich sein die eine Unterweisung oder vergleichbare Praxiserfahrung mit Maschinen dieser Art besitzen.
-Maschinen können automatisch eingeschaltet werden wenn eine Zugriffsberechtigte Person das wünscht.
-
-
+Nutzung von Maschinen soll nur denjenigen möglich sein die eine Unterweisung
+oder vergleichbare Praxiserfahrung mit Maschinen dieser Art besitzen.
+Maschinen können automatisch eingeschaltet werden wenn eine Zugriffsberechtigte
+Person das wünscht.
 
 
 \section{Zustands-Anzeige}
@@ -47,32 +48,57 @@ Zentrales Dashboard
 
 \section{Management}
 
+
 \begin{itemize}
 \item Nutzer und Maschinen müssen hinzugefügt werden können.
 \item Nutzer und Maschinen müssen wie bei QR-Hello „on the fly“ hinzugefügt werden können.
 \item Nutzer \& Maschinen können auch aus externer Datenquelle geholt werden.
+\item Maschinen können blockiert werden um nicht weiter ausleihbar zu sein.
 \item Berechtigungen können editiert werden.
 \item Maschinen können zentral (sicher) ausgeschaltet werden.
 \item Das Ausschalten soll mit Vorlauf (z.B. 30 min) möglich sein.
 \end{itemize}
 
+Es gibt einen Management-Client der alle oben genannte Funktionalität bereitstellt
+
 \section{Abrechnung}
 Abrechnung nicht intern sondern über extere ERP-Software (odoo / ...)
 
+\section{Audit}
+Zugriff/-gang wird in einem festen, strukturierten Format geloggt was von einer
+externen applikation genutzt werden kann um Vorgaenge zu ueberwachen
+
 \section{Komponenten}
 
-Angeschlossene Schnittstellen-HW unterteilt sich in Sensoren (RFID-Leser / Stromsensoren / ...) und Aktoren (Schalter / Displays / ...)
-Es gibt eine Schnittstelle, die es erlaubt, über ein Plugin-System hardware-spezifischen Code anzubinden. Das Modulsystem soll sprachagnostisch (python / lua / ...) sein.
+Angeschlossene Schnittstellen-HW unterteilt sich in Sensoren (RFID-Leser /
+Stromsensoren / ...) und Aktoren (Schalter / Displays / ...)
+Es gibt eine Schnittstelle, die es erlaubt, über ein Plugin-System
+hardware-spezifischen Code anzubinden. Das Modulsystem soll sprachagnostisch
+(python / lua / ...) sein.
+
+Geraete koennen Sensoren, Aktoren oder beides enthalten.
+Eine Statusanzeige am Gerät würde hier als Aktor implementiert
 
 \subsection{Sensoren}
 
+Sensoren benachrichten Backend über Events (z.b. RFID-Karte an Leser gehalten,
+Knopf gedrückt), bekommt ACK zurück um At-Least-Once Messaging zu
+implementieren.
+
 \subsubsection{RFID-Leser}
-Es sollen sowohl "plain" als auch Crypto-Karten (Mifare DESfire EV1) möglich sein.
+Es sollen sowohl ``plain'' als auch Crypto-Karten (Mifare DESfire EV1) möglich sein.
 
 \subsubsection{Knopf}
 
 \subsection{Aktoren}
 
+Aktoren bekommen Aktionsanfragen (z.b. öffne Relais, schließe Relais), können
+über Erfolg berichten.
+
+Protokoll encoded erwarteten Zustand, nicht Zustandsänderung um At-Least-Once
+Messaging zu vereinfachen. Das bedeutet aber im Umkehrschluss das ein Aktor die
+Zustandsänderung selber herausfinden muss.
+
 \subsubsection{Schalter}
 
 \subsubsection{Display}
@@ -83,6 +109,7 @@ Ist geplant, über den Prototype-Fund zu finanzieren.
 
 \begin{itemize}
     \item Federation
+    \item Reservierungen anstatt nur in situ Nutzung (z.b. fuer Konferenzraeume recht sinnvoll)
 \end{itemize}
 
 \subsubsection{Far Future}