Project User Interface Nodes
Inleiding
De Makerspace heeft in de afgelopen jaren een redelijk aantal zogenaamde 'Nodes' gekregen, voornamelijk om toegang tot apparaten te verlenen, maar ook betaalterminals, sensoren, enzovoort. Een van de zaken die er bij deze organische groei gebeurt, is dat het voor nieuwe (en soms ook oude) gebruikers soms een raadsel is hoe ze werken. En dan heb ik het niet over de techniek, maar hoe ze zich 'aan de buitenkant' gedragen.
Dit is een klein projectje om te komen tot een user interface standaard voor onze nodes, die bedoeld is om het voor gebruikers makkelijker te maken om ze te gebruiken.
Belangrijke aspecten zijn de volgende:
- Inzichtelijkheid: dat het voor de gebruiker duidelijk is waar het apparaat voor is, wat de mogelijkheden zijn, en wat de toestand op een bepaald moment is.
- Consistentie: dat iedere node zich zo veel mogelijk als de andere nodes gedraagt. Dat een rood lampje niet de ene keer betekent dat het apparaat aan is, en een andere keer dat er een fout is.
Inleiding
Onderscheid in functionele modules
In veel van de Nodes worden een aantal functionaliteiten gecombineerd. Dit maakt dat het voor veel gebruikers onduidelijk is wat er precies mis is en waar de oplossing gezocht moet worden.
De volgende functionaliteiten worden in dit stuk onderscheiden, mogelijk worden daar nog extra aan toegevoegd:
- Contact met de server
- Autorisatie
- Apparaatbesturing
- Onderhoud
In het verhaal hieronder worden deze apart besproken, ook al kunnen deze functionaliteiten heel goed samen in een enkele techische module / processor gerealiseerd worden.
Wat doen we met onze legacy waar deze scheiding nog niet in gedaan is?
Veelheid aan statussen en zichtbaarheid
Uit het verdere verhaal hieronder volgt dat er een veelheid aan omstandigheden een rol kunnen, waarvan het handig is als iedere omstandigheid apart gevisualiseerd kan worden.
In praktijk zijn we echter gebonden aan economische factoren, zoals het aantal outputs waarmee we apart iets kunnnen aangeven met bv een lampje, en dat een volledig display duur is zowel financieel als in ontwikkelingsinspanning.Oplossingen kunnen eventueel gevonden worden in I2C expanders of NeoPixel om meerdere leds aan te sturen met weinig pinnen.
In het verhaal hieronder is gekozen om als eerste te bedenken hoe we zaken kunnen weergeven zonder ons te bekommeren om de technische complexiteit.
Deze complexiteit zal uiteindelijk wel vormgegeven moeten worden.
Monitoren van de Verbinding met de Server
Probleem
Onze nodes zijn niet continu in contact met het netwerk cq met de server, maar wordt er per autorisatieverzoek asynchroon een bericht uitgewisseld volgens een request-response patroon.
Het gevolg hiervan is dat je aan een node die in rust is, niet kunt zien of deze goed aangesloten is op het netwerk cq op de server of niet. Je komt er in praktijk pas achter wanneer je een autorisatie-poging doet, en deze faalt. En dan nog weet je vaak niet of deze faalt omdat de verbinding er uit ligt of dat er een ander probleem is. Ook is niet duidelijk of het netwerk zelf het probleem is, bijvoorbeeld of de node geen wifi signaal ontvangt, of dat de server niet reageert, of dat de server wel reageert maar met een bepaalde fout.
Op dit moment is het noodzakelijk om de node aan een laptop te hangen of de logs te analyseren. Dit vereist een hoeveelheid specialistische kennis die nu maar bij een beperkt aantal mensen beschikbaar is en die mensen hebben lang niet altijd tijd om dit te doen.
Voorstellen
Onderstaande voorstellen zijn bedoeld om makkelijker (dwz zonder specialistische kennis of middelen) te kunnen zien of de verbinding goed is en wanneer niet, waar de oorzaak ligt.
- In de gebruikersinterface een deel te reserveren voor het visualiseren van de status van de verbinding,bijvoorbeeld door dat deel van de interface als zodanig te markeren met een label en een kader.
Dit is nodig om te voorkomen dat verbindingsproblemen worden opgevat als problemen van andere aard en vise versa. - Waar mogelijk de interface met de server uit te breiden met een ping mechanisme (request-response), waardoor de status van de verbinding los beoordeeld kan worden van de autorisatie.
Bijvoorbeeld dat iedere x seconden een bericht naar de server gestuurd wordt waar de server technisch positief op hoort te reageren. - De interface uit te breiden met een negatieve autorisatie response.
- De status van de verbinding te visualsieren met een blauw lampje, een rood lampje en een groen lampje, eventueel gecombineerd in een multi-color led.
- Een blauwe puls, iedere keer als er een request aan de server gestuurd wordt (ping request of los autorisatie-request).
De frequentie moet zodanig gekozen worden dat deze ruim groter is dan de normale respons-tijden (zie ook time-out). - Een groene puls, iedere keer als er een technisch positieve reacte van de server ontvangen wordt.
De puls kan onregelmatig zijn, omdat de server niet altijd met dezelfde snelheid reageert.
Technisch positief betekent overigens niet per se functioneel positief (=positieve autorisatie). - Een rode puls iedere keer als er een technisch negatieve bevestiging (of time-out) wordt ontvangen:
- Continu rood: er is uberhaupt geen wifi/ethernet
- 1 puls: er is geen reactie van de server binnen de vastgestelde time-out
- 2 pulsen: er is wel een reactie ontvangen van de server, maar deze wordt niet begrepen door de node
- 3 pulsen: er is wel een reactie ontvangen van de server, maar de server zegt het request niet te kunnen afhandelen
- 4 pulsen: .....
- Een blauwe puls, iedere keer als er een request aan de server gestuurd wordt (ping request of los autorisatie-request).
Monitoren van de Autorisatie
Probleem
In de huidige situatie is het nog wel eens onduidelijk dat wanneer een apparaat niet aan gaat, of dit een probleem is met de netwerkverbinding, met de identificatie en/of autorisatie, of een probleem met het te besturen apparaat zelf. De gebruiker weet dan vervolgens niet waar die de oorzaak moet zoeken. Het doel van de standaard is mede om hier verbetering in aan te brengen.
Voorstellen
Onderstaande voorstellen hebben als doel om goed zichtbaar te maken of de autorisatie goed verloopt, en zo nee, waar de oorzaak gezocht moet worden.
Voorstellen:
- In de gebruikersinterface een deel te reserveren voor het visualiseren van de status van de autorisatie,bijvoorbeeld door dat deel van de interface als zodanig te markeren met een label en een kader.
Dit is nodig om te voorkomen dat autorisatieproblemen worden opgevat als problemen van andere aard en vise versa. - De interface tussen Node en Server uitbreiden met een negatieve autorisatie response. Op dit moment is deze er nog niet om veiligheidsredenen, maar deze zou alsnog veilig gebouwd kunnen worden.
- De status van de autorisatie te visualsieren met een blauw lampje, een rood lampje en een groen lampje, eventueel gecombineerd in een multi-color led.
- Lampje brandt niet: De Node (of de autorisatie-functie) staat uit.
- Het blauwe lampje is primair bedoeld om de status autorisatieproces weer te geven
- Brandt continu: Node staat klaar om de RFID te lezen.
- Brandt knipperend: Node werkt niet volledig/correct of is bezig. Uit knipperpatroon is af te leiden wat er aan de hand is.
- Periodiek 1 korte puls: aan het opstarten
- Periodiek 2 korte pulsen: (nog) geen netwerk (zie onder Monitoren van de verbinding)
- Periodiek 3 korte pulsen:Node wacht op autorisatie van de server (wellicht overbodig, zie onder Monitoren van de Verbinding)
- Periodiek 4 korte pulsen: Node is geconfigureerd om altijd geforceerd een positieve autorisatie af te geven => Zou ook met een patroon in de groene led kunnen
- Periodiek 5 korte pulsen: Nodie is geconfigureerd om altijd geforceerd een negatieve autorisatie af te geven => Zou ook met een patroon in de rode led kunnen
- .....
- Het groene lampje is primair bedoeld om een positieve autorisatie aan te geven:
- Brandt continu: Gebruiker is herkend en is geautoriseerd.
NB: Dit lampje blijft groen zo lang de autorisatie geldt, dat wil zeggen:- Totdat een bepaalde timer verloopt
- Totdat het apparaat uitgezet wordt (vereist een input vanuit de apparaatsturing)
- Totdat de huidige gebruiker zich afmeld (is dit nodig? hoe doen we dat? aparte input of aparte state?)
- Totdat een nieuwe gebruiker zich aanmeldt
- .....
- Het rode lampje is primair bedoeld om een negatieve autorisatie aan te geven:
- Brandt continu: Autorisatie is geblokkeerd
- Brandt 1x kort: Fout bij lezen RFID
- Brandt 3x kort: Gebruiker is wel herkend maar niet geautoriseerd.NB: Dit werkt niet zo lang er nog geen negatieve autorisatie response ondersteund wordt.
- Brandt 5x kort: Gebruiker is niet herkend
- Brandt continu: Gebruiker is herkend en is geautoriseerd.
DW: Kleine complexiteit - indien er slecht/traag/geen netwerk is - wordt er een cache gebruikt. Dus nu is het slecht onderscheid maken tussen een geen antwoord server, te traag antwoord server en niet in cache en werkelijk niet herkend. Dus je kan ook hebben - scan; geen antwoord in 0.5 seconden; check cache; niet gevonden; 1 seconde later - toch traag ok van server. En dan gaat de deur open - want we negeren zo'n transient 'niet gevonden' en geven het pas na 5 seconden oid op.
''We kunnen wel betrouwbaar vaststellen dat de RFID ok gelezen is.'Sommige nodes snappen het verschil tussen Authentificatie en Authorisatie; i.e je bent herkent als persoon X maar je mag (alleen) A en niet B.'FZ: Hoe doe je het dan als je iemand snel de toegang wil ontzeggen? Bv omdat die met een dreigement komt? Zo lang diens token in de cache van de toegangsdeur zit kan die binnenkomen.'''DW: Kleine complexiteit -- een aantal nodes doet niet aan authorisatie/etc - maar detecteert of stuurt alleen. Die hebben geen RFID.'FZ: Welke zijn dit? Wat doen die? Hier wellicht nog aparte secties voor schrijven?
Monitoring van de Apparaatsturing
NB: Met de Monitoring van de Apparaatsturing bedoelen we niet hetApparaatveiligheidssysteem zelf, maar slechts de waarneming van de toestand daarvan.
Probleem
Ondanks dat de autorisatie van een apparaat in orde lijkt te zijn (wat lang niet altijd duidelijk is, zie hierboven), lukt het soms niet om het apparaat aan de gang te krijgen.
De oorzaken kunnen legio zijn, bijvoorbeeld:
- Dat het apparaat zelf geen netspanning heeft (op de ingaande kant van de beveiliging)
- Dat het apparaat al aan stond (op de uitgaande kant van de beveiliging)
- Dat er een noodknop ingedrukt is
- Dat het apparaat zelf een storing heeft afgegeven (bv oververhitting)
- Dat er een externe voorwaarde niet is ingevuld (bv afzuiging)
- .... graag extra voorbeelden aangeven!
Voorstellen
- In de gebruikersinterface een deel te reserveren voor het visualiseren van de status van de apparaatbesturing,bijvoorbeeld door dat deel van de interface als zodanig te markeren met een label en een kader.
Dit is nodig om te voorkomen dat apparaatbesturingsproblemen worden opgevat als problemen van andere aard en vise versa. - De status van de monitoring weer te geven met aparte lampjes per deelaspect
- Netspanning: Groen = Spanning, Uit = geen spanning
- Apparaatspanning: Groen = Spanning, Uit= geen spanning
- Spanningsuitval: Rood knipperend = Netspanning is van aan naar uit gegaan terwijl het apparaat op 'aan' stond
- Heractivatie: Rood knipperend = Netspanning is van uit naar aan gegaan terwijl het apparaat op 'aan' stond
- Dubbele activatie: Rood knipperend = Stuurpuls voor 'aan' ontvangen terwijl het apparaat al aan stond
- Noodknop: Rood knipperend = Er staat een noodknop op 'uit' (hier kunnen er verschillende van zijn)
- Apparaatstoring: Rood knipperend = apparaat geeft een storing aan (hier kunnen er verschillende van zijn)
- Externe voorwaarde: Rood knipperend = voorwaarde is niet ingevuld (hier kunnen er verschillende van zijn)
Onderhoud
In de huidige situatie is er steeds vaker de behoefte om een apparaat, ongeacht wat de autorisatie op een bepaald moment zegt, handmatig aan te zetten of uit te zetten in een onderhoudscontext.
Het handmatig aan zetten is vooral in de situatie dat er aan het apparaat gewerkt moet worden waarbij het aan moet zijn,ook al is de autorisatie-kant nog niet geregeld. Ook bijvoorbeeld als het apparaat naar huis genomen is voor onderhoud.
Het handmatig uit zetten is vooral in de situatie dat er iets mis is aan het apparaat of dat het apparaat nog niet vrijgegeven is voor gebruik, en voorkomen moet worden dat iemand het apparaat per ongeluk toch aan zet.
Vraagstukken:
- Autorisatie: wie mag wel en niet een Manual Override te doen
- Sturing versus weergave
- Binnen de autorisatie-module of binnen de apparaatsturingsmodule
- Hardwarematig en/of softwarematig, samenhang daarbij
Huidige states en signalen =
Aart LED
Huidige Aart LED (Groen bij de meeste machines) - typisch
- Langer dan 5 seconden uit - CPU hangt of geen power.
- Langzame flash - alles normaal
- kortje flitsjes - kaart gescanned en wordt gechecked.
- Snelle flash voor 1-2 seconden - kaart rejected, timeout, etc -- transient fout
- Snel lang flashen - er is iets mis
- In sommige gevallen kan dit iets in het safety circuit zijn - zoals de operator switch op ON, een ingedrukte noodstop of de detectie van een lopende motor terwijl die uit zou moeten zin
- Morse patroon - er is iets 'echt' miss - zoals geen netwerk, stroom, etc.
- Continue aan - machine vrijgegeven
Uitzonderingen zijn de deur nodes.
Typische definitie:
{ "Booting", LED::LED_ERROR, 120 * 1000, REBOOT },
{ "Out of order", LED::LED_ERROR, 120 * 1000, REBOOT },
{ "Rebooting", LED::LED_ERROR, 120 * 1000, REBOOT },
{ "Transient Error", LED::LED_ERROR, 5 * 1000, WAITINGFORCARD },
{ "No network", LED::LED_FLASH, NEVER , NOCONN }, // should we reboot at some point ?
{ "Waiting for card", LED::LED_IDLE, NEVER , WAITINGFORCARD },
{ "Checking card", LED::LED_PENDING, 5 * 1000, WAITINGFORCARD },
{ "Rejecting noise/card", LED::LED_ERROR, 5 * 1000, WAITINGFORCARD },
{ "Powered - but idle", LED::LED_ON, NEVER , WAITINGFORCARD }, // we leave poweroff idle to the code below.
{ "Running", LED::LED_ON, NEVER , WAITINGFORCARD },
// LED patterns:
//
typedef enum { LED_OFF, LED_FLASH, LED_SLOW, LED_FAST, LED_ERROR, LED_PENDING, LED_IDLE, LED_ON, NEVERSET } led_state_t;
// 01234567012345670123456701234567
#define PATTERN_IDLE 0b10000000000000000000000000000000
#define PATTERN_EVEN 0b10101010101010101010101010101010
#define PATTERN_SO 0b11100111100111001001001000000000
#define PATTERN_A 0b11000000111111000000000000000000
State engine NODE
- Node is uit
- Node is powered
- Node is Out-of-Order/locked in the CRM - it won't react to anything until that is unlocked.
- Oude nodes - 1 of 2 hebben een zichtbare powerled
- Vanaf generatie WNH - allemaal een powerled; niet altijd zichtbaar.
- Node heeft volledig geboot / geen netwerk
- Leeuwendeel van de nodes heeft een of andere indicatie (AartLed)
- WNH: led of display
- Waiting for card
- Leeuwendeel van de nodes heeft een of andere indicatie (AartLed)
- WNH: led of display
- Card word geswiped
- Oude nodes: sommige geven een piepje
- WNH: allemaal een buzzer met korte piep; meeste display
- Denied of time-out of geen netwerk -EN- niet in de cache
- Oude nodes: meeste geven een LED signaal
- WNH: buzzer signaal
- Approved (via de server of via de cache als er geen netwerk is)
- Oude nodes: meeste geven een LED signaal. sommige alleen klick (tussendeur), buzzer (voordeur) of stappenmotor (spacedeur)
- WNH: Allemaal buzzer; meeste display text
- Indrukken van een of andere 'uit knop'
- Node valt terug naar waiting for card.
Sommige nodes
- Led of buzzer signaal indien de safety interlock een probleem heeft.
State safety interlock
- Geen power
- Power; en in de veilige stand
- kan niet aan - noodknop ingedrukt
- kan niet aan - clickson of andere interlock in motor (zoals open deur) blokkeert dit
- kan niet aan - de operator switch staat in de 'aan' stand.
- kan niet aan - niet vrijgegeven door de node
- kan niet aan - er ontbreekt een fase (maar bij één machine)
- kan aan met rode knop - paar nodes hebben dan een lamp die aan gaat
- operator switch van uit->aan
- Motor gaat lopen
- operator switch van aan->uit
- Motor stopt
- Iets dat de interlock verbreekt (node crash, noodknop, overload, overtemp, deurtje open, etc)
- Naar veilige staat
- Meeste nodes - node ziet dit, blokkeert vrijgave onmiddelijk & stuurd warning naar MQTT
- Groene knop ingedrukt bij motor UIT- apparaat naar veilige staat
- Meeste nodes - node ziet dit en stopt na 10-120 seconden de vrijgave van de safety
- Groene knop ingedrukt bij motor AAN - apparaat naar veilige staat
- Meeste nodes - node ziet dit, blokkeert vrijgave onmiddelijk & stuurd warning naar MQTT en soms beheerders/bestuur
