Cloud-alarmeringsplatform voor verbonden sensoren

Een productteam voor verbonden hardware kwam bij ons met een werkend sensorprototype. Zodra een meetwaarde een ingestelde drempelwaarde overschreed, verstuurde het een melding via een externe notificatiedienst. Daarmee was het concept bewezen, maar verkopen kon het niet: er was geen apparaatregister, geen gestructureerde eventdata en geen manier om units te bereiken die al in het veld waren geïnstalleerd. CYBORG heeft het volledige cloudplatform eronder ontworpen en gebouwd, en is tijdens elke fase van de uitrol betrokken gebleven.

• Van begin tot eind geleverd: discovery en architectuur, het MVP-platform, de operationele laag en het klantportaal.
• Sensoren maken verbinding via mobiel LTE-M, onafhankelijk van het eigen netwerk van de klant.
• Drempelwaarde-events bereiken de telefoon van de gebruiker binnen enkele seconden als pushmelding.
• Meldingen komen binnen via een Progressive Web App, zonder tussenkomst van een app store.
• Reeds uitgerolde apparaten worden beheerd en over-the-air bijgewerkt, zonder bezoek ter plaatse.

Afhankelijkheid van een derde partij:
Elke melding in het prototype liep via een externe notificatiedienst die ook de apparaatnamen, de ontvangerslijsten en de berichtteksten beheerde. De productroadmap, en de klantgegevens, lagen in een tool die het bedrijf niet zelf in handen had.

Geen apparaatidentiteit:
Sensoren hadden geen unieke inloggegevens en geen register erachter. Er was geen manier om vast te stellen welke fysieke unit een melding had verstuurd, om een unit in te trekken, of om te weten of een uitgerold apparaat nog online was.

Ongestructureerde events:
Het prototype verstuurde een ad-hoc API-aanroep in plaats van een gedefinieerd bericht. Zonder een stabiel schema was er geen meldingshistorie, geen rapportage en geen veilige manier om de firmware en de cloud onafhankelijk van elkaar door te ontwikkelen.

Geen weg terug naar het apparaat:
De communicatie verliep één kant op. Drempelwaarden konden niet worden aangepast, units konden niet worden geactiveerd of gedeactiveerd, en firmware kon alleen worden bijgewerkt door de installatie fysiek te bezoeken.

Geen model voor installaties:
Eén sensor die één telefoon een melding stuurt, werkt als demo. Een commerciële uitrol vraagt om klanten, locaties, apparaatgroepen en meerdere ontvangers per groep, en dat bestond allemaal nog niet.

Geen weg naar selfservice:
Elke wijziging in een ontvangerslijst of een drempelwaarde zou als supportverzoek bij het productteam terechtkomen, wat een harde grens legt op het aantal installaties dat het bedrijf aankan.

Discovery vóór de bouw:
We begonnen met een korte discovery-fase samen met het hardwareteam om de systeemarchitectuur, het communicatiemodel tussen apparaat en cloud en de exacte structuur van het eventbericht vast te leggen. Dankzij dat contract konden firmware en cloud parallel worden ontwikkeld zonder elkaar te blokkeren.

Beheerde IoT-connectiviteit:
Apparaten publiceren via MQTT naar AWS IoT Core met een certificaat per apparaat en een persistente verbinding. Een mobiele LTE-M-verbinding houdt de unit volledig buiten het netwerk van de klant, wat de meest voorkomende oorzaak van mislukte installaties wegneemt.

Een vastgelegd eventcontract:
Elke melding bevat een apparaat-ID, eventtype, tijdstempel, sensorwaarde en firmwareversie. Die ene keuze maakte meldingshistorie, monitoring van de apparaatstatus en later ook analyses mogelijk zonder opnieuw de firmware aan te passen.

Event-gedreven notificatierouting:
Een binnenkomend event wordt direct bij aankomst gevalideerd, opgeslagen en gekoppeld aan de ontvangers van de betreffende apparaatgroep. Er wordt niet gewacht op een geplande taak, en dat is wat de end-to-end levering binnen enkele seconden houdt.

Progressive Web App voor meldingen:
Gebruikers installeren de meldingsapp rechtstreeks vanaf een browserlink en ontvangen Web Push-meldingen op hun telefoon. Eén codebase bedient zowel iOS als Android, en verbeteringen gaan dezelfde dag live in plaats van te wachten op beoordeling door een app store.

Een gestructureerd datamodel:
Klanten, installaties, apparaatgroepen, individuele sensoren en geregistreerde gebruikersapparaten zijn expliciet gemodelleerd in PostgreSQL. Een locatie toevoegen of een apparaat naar een andere groep verplaatsen is een beheerhandeling in plaats van een codewijziging.

Operationeel dashboard:
Een intern webdashboard geeft het operationele team live inzicht in de online- en offlinestatus van elke uitgerolde unit, de volledige meldingshistorie en de bewaking van de bezorging, zodat een stille sensor wordt opgemerkt voordat een klant zich meldt.

Tweerichtingsbesturing en OTA:
Hetzelfde MQTT-kanaal draagt commando's terug naar het apparaat. Drempelwaarden kunnen worden bijgesteld, units geactiveerd of gedeactiveerd, diagnostiek opgevraagd, en ondertekende firmware kan draadloos worden uitgerold naar sensoren die al geïnstalleerd zijn.

Selfserviceportaal voor klanten:
Klantbeheerders beheren hun eigen apparaatgroepen, gebruikers en meldingsregels, met rapportage over hun eigen eventhistorie. Routinematige wijzigingen zijn geen supporttickets meer, terwijl de centrale operationele controle bij het productteam blijft.