Direkt zum Hauptinhalt

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)

  • Wieviel Logik sollte / Muss in der Hardware implementiert sein? Um verschiedene Hardware (Leser mit/ohne Diplay, mit/ohne Relais, mit/ohne Leistungserfassung) zu unterstützen wäre der Vorschlag, möglichst viel Logik in die Software (Back-end?) zu implementieren.
  • In welcher Form werden anzeigbare Nachrichten übermittelt (als Klartext oder als Befehl, der dann von der Hardware interpretiert wird)? Vorschlag ist mit Befehle zu arbeiten, da dies ebenfalls mehr Flexibilität bei der Hardware (unterschiedliche Displays) ermöglicht. Nachteil ist, das man nicht so flexibel in der Erweiterung der Anzeigetexte ist (dies eine Neuprogrammierung der Hardware erfordert)
  • Wenn die Lesegeräte unabhängig sind von den Aktuatoren, ist die “Notfreischaltung” bei Software oder Netzprobleme nicht möglich. Entweder Implementiert man hier eine direkte Kommunikation zwischen Leser und Aktuator über den Broker oder muss den Aktuator von Hand schalten. Was ist bevorzugt?
  • Die Idee ist, die Hardware über einen Setup-modus als Access Point zu konfigurieren. Hier wird die Broker-IP, Geräte-ID etc. eingetragen. Hier kann auch das Verahlten (z.B. Log-out über RFID Karte oder einfach per Taste) konfiguriert werden.
  • Sollte die Hardware ESP8266 basiert sein, gibt es nur den Analog-Eingang um eine Taste zu integrieren. Solle mehr als eine Taste benötigt werden, wird man z.B. auf dem ESP32 umschwenken müssen (Eine Taste wird z.B. für Bestätigung der Beaufsichtung der Maschine im Betrieb benötigt). Welche Szenarien für Tastennutzung gibt es?
    • Eine Variante ist z.B. der Wemos D1 oder NodeMCU v3 … 8266 mit mehr herausgeführten digitalen Anschlüssen als der ESP01. (TMu, 2020-08-11)

Lastenheft vorstellen / durchsprechen.

Fragen(Joris):

Anforderungsliste:

  • 4 Override -> So wie es hier beschreiben ist erfordert dies eine Integration von Kartenleser und Leistungsmodule. Bei Verwendung von separaten Leistungsmodule (z. B. Tasmota) könnte dies manuell über eine Taste erfolgen (somit ungesichert). Hier würde mich die Erfahrung von Card2Go interessieren.
    • An der Stelle ist bei den Prototypen für Card2Go tatsächlich Card-Reader und Schaltmodul (im Protoyp eine LED, später Relais / SSR / Schütz) eine Einheit … bzw. der Card-Reader hat einen direkten Ausgang, über den er das Schaltmodul betätigen kann. (TMu, 2020-08-11)
    • In der Firmware vom CardReader sind dann “Master-Karten” (rote Karte / grüne Karte) hinterlegt, die nicht gegen das Backend verifiziert werden, sondern die direkt und ohne Rückfrage schalten. (TMu, 2020-08-11)
  • 8 Nutzerhinweise ausgeben -> hier ist die Frage wo welche Nutzerhinweise hinterlegt sind, bzw. wie sichergestellt wird, dass diese auch sinnvoll formatiert auf die Anzeigen angezeigt werden (je nach Hardware).
    • Ein Beispiel ist dass 30 Minuten vor dem finalen “Strom ist weg” in der Anzeige ein Zähler rückwärts läuft, der den Nutzer sachte drauf hinweist dass er evtl. mal langsam ans Ende denken sollte, wenn er noch Zeit / Strom braucht um die Maschine ordentlich herunterzufahren / zu putzen. Hilft drastisch, einen geordneten Feierabend im Labor hinzubekommen / durchzusetzen.
    • Wieder abhängig von Berechtigungen … es wird sicher Nutzer geben, die auch nach “Feierabend” da bleiben und aufräumen dürfen. (TMu, 2020-08-11)
  • 11 Reservierung von Maschinen -> gibt es hier ein angedachtes Konzept (z.B. Erfahrung von andere Systeme). Reservierung ist unter Punkt 13 in die Zukunft verschoben?
    • Reservieren im offenen Werkstattbereich ist … nicht offen. (“Handtuch-Mentalität” entgegenwirken.)
      • A: Maschine ist reserviert, Fertigungs-Daten sind nicht fertig (im Sinne von “wirklich fertig!”) -> die Maschine steht, obwohl jmd. anders sie nutzen könnte.
      • B: Maschine ist morgen reserviert, Fertigungs-Daten sind aber unerwartet früh (jetzt) schon fertig -> Ich kann erst morgen weitermachen, obwohl ich faktisch schon heute könnte.
    • Reservierung ist z.B. in begrenztem Umfang sinnvoll … der normale Weg ist “first come, first serve” … mit einer möglichen Priorisierung (z.B. in einer Lehr-Hochschule: “Lehre vor Forschung vor Privat vor Industrie”) (TMu, 2020-08-11)
      • ich sitz zuhause, hab ca. 45 Minuten bis zum Lab, seh im Netz dass die Maschine frei ist und möchte nicht umsonst hinfahren, weil mir in 10 min. jemand die Maschine wegschnappt während ich unterwegs bin.
      • Im Lab ist jeden Mittwoch um 14:00 bis 15:00 Maschineneinweisung.
    • Grundsätzlich: Freie Maschinen können genutzt werden, arbeitende Maschinen erst wieder, sobald sie fertig (geputzt / abgenommen) sind. Toilettenpause ohne Maschinenrückgabe ist dabei okay, Mittagessen grenzwertig, “am nächsten Tag geht’s weiter” ist üblicherweise indiskutabel. (TMu, 2020-08-11)
  • 13 Relation Zeit-Maschine -> dieser Punkt klingt für mich etwas kryptisch. Erläuterung erhofft :-)
  • 15 Öffnungszeiten festlegen -> hier würde ich ein Maschinenbezogenes Konzept wünschen. Zenario wäre hier, dass aufgrund von Auflagen, bestimmte Maschinen spezifische Nutzungszeiten haben.
  • 19 Statusanzeige -> Hier würde ich mir einige konkrete Beispiele als Szenario wünschen.
allgemeine Fragen:
  • allgemein wird an einigen Stellen von “Maschine übergeben” geschrieben. Da mir aktuell noch die Praxis fehlt, ist das für mich noch etwas vage. Hier würde mir ein Praxis-Zenario helfen
    • Ein Szenario ist z.B. Nutzer 1 (A) ist eigentlich fertig, würde jetzt anfangen die Maschine zu putzen und zurückzugeben. Nutzer 2 (B) steht ningelnd daneben und würde gerne schnell und unbyrokratisch übernehmen. B kann dann von A die Maschine unter der Bedingung übernehmen, dass er die volle Verantwortung für etwaige Schäden die auf dem Mist von A gewachsen sind … und für das Putzen und zurückgeben der Maschine übernimmt. Die Idee ist an der Stelle, beim Weggang von A ein (definierbares) Zeitfenster von z.B. 15 Sekunden zu lassen, innerhalb dessen ein B (mit entsprechender Berechtigungs-Kombination aus “darf übernehmen” und “darf diese Maschine jetzt bedienen”) die Maschine direkt übernehmen kann. Das Zeitfenster muss dabei so kurz sein, dass A in jedem Fall mitbekommen kann, wenn jemand übernimmt. (TMu, 2020-08-11)
    • Konkret: A nimmt die RFID-Karte weg, B muss die Option freigeschaltet haben und innerhalb von 15 Sekunden seine Karte auflegen, dann “gehört” ihm die Maschine und er kann los legen. (TMu, 2020-08-11)
  • Ist die “Eingangstür-Kontrolle” (z.B. bei 24/7 Zutriff) ebenfalls mit drin oder soll dieser ausgeschlossen werden?
    • Soweit eine Eingangstür eine “Maschine” ist, die bei Nutzung jeweils für ca. 5 Sekunden einschaltbar ist. Ja. Wenn die Eingangstür eine “Maschine” ist, von deren Funktion die Sicherheit im Lab oder die einzige Zutritts-Option, die zudem nicht anderweitig verhindert werden kann abhängig ist … nope.
    • Konkret:
      • Wenn ein zusätzliches (mechanisches) Schloss existiert und mit FabAccess nur wenn dieses aufgesperrt ist, die Tür geöffnet werden kann … okay.
      • Wenn eine Panikschließung existiert, so dass man von innen jederzeit raus kommt … okay.
      • Wenn man durch Yberlisten von FabAccess sofort unbefugten Zutritt zum Lab bekommt … nicht okay.
      • Wenn man bei Stromausfall (durch FabAccess) nicht mehr raus kommt … nicht okay. (TMu, 2020-08-11)
    • Final entscheiden muss das am Ende jedes Lab für sich. Seitens FabAccess ist da allerdings halbwegs klare Kommunikation wichtig, damit die Labs das auch wirklich und richtig informiert entscheiden können. (TMu, 2020-08-11)
  • Authentifizierung über SASL -> relevant für die Hardware+Code?
  • Abrechnung (Non-Features) -> das macht Sinn, aber hier würde ich mir schon ein “nutzbaren” Output wünschen der in einer Abrechnugnssoftware weiterverwendet werden kann. Was ist hier aktuell angedacht?

Sonstiges

nach oben